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Resumes 


Introduction aux caracteristiques techniques d’un RNIS 
Marc Orange, ICL Network Applications, Vetizy, France^ p. 451 

“La caracteristique principale d’un RNIS est d’assurer, au sein d’un meme 
reseau, une large gamme de possibilites d’applications telephoniques et non 
telephoniques”. 

Cet article a pour objectif d’expliciter cette breve definition issue du 
C.C.I.T.T. II commence par decrire les caracteristiques de base du RNIS, 
et donne ensuite une vue d’ensemble des protocoles RNIS mis en oeuvre au 
niveau de I’interface Acces de Base. 

RNIS en France: Numeris et son Marche 

L. Calot and A. Spiracopoulos, ICL Network Applications, IT Services, Velizy, 
France^ p. 468 

Cette article donne un apergu du Reseau Numerique a Integration de 
Services (RNIS) en France, appele NUMERIS, et de son marche. 

D’abord, il decrit revolution technique de NUMERIS, les differents reseaux 
de transmission de donnees pre-RNIS, et I’implementation de NUMERIS. 
Ensuite, le RNIS correspondant a un changement important dans le monde 
des telecommunications, il convenait d’elaborer un marketing “subtil”. Dans 
cet article nous presentons la strategic mise en place par France Telecom, 
et conclurons par I’offre des terminaux et applications existantes sur le 
marche frangais. 

L’Expansion du marche des Telecommunications en Espagne 
J. Larraz, ICL Madrid, Spain^ p. 493 

L’Espagne doit etre prete pour le challenge de 1992. Les usagers et les 
fournisseurs semblent envisager cette annee I’augmentation de I’utilisation 
et du developpement des produits de communication. Cependant, I’offre 
d’un reseau numerique a integration de Services (RNIS) semble representer 
le plus grand point d’interrogation. 

Futures Applications du Reseau Numerique a Integration de Services dans 

le Domaine des Technologies de I’lnformation 

A. R. Fuller, ICL Network Systems, Windsor, UK^ p. 501 

Cet article examine les avantages offerts aux utilisateurs d’ordinateurs par 
les communications sur reseau numerique a integration de services (RNIS). 
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II demontre que le RNIS se prete particulierement a de nouvelles applications 
qui sinon seraient difficilement realisables ou trop couteuses. II decrit ensuite 
I’application de “Desk-Top Conferencing” qui a fait Tobjet de demonstra¬ 
tions par STC/ICL. Cette application multi-medias permet a deux ou plusie- 
urs personnes d’echanger des informations vocales ou visuelles pour, par 
exemple, travailler ensemble sur des donnees textuelles ou graphiques. 

II presente enfin les nouvelles possibilites offertes par le RNIS aux applica¬ 
tions futures. 

Un Systeme dTnformations Geographiques pour la Gestion de I’Actif d’une 
Compagnie des Eaux 

C. E. H. Corbin, IT Southern Ltd, Brighton, UK, p. 515 

Cet article decrit la maniere dont la technologic de I’information traite les 
problemes commerciaux lies a la gestion de I’actif immobilise d’une compag¬ 
nie des eaux. Cette compagnie possede des actifs de 2,469 millions de livres 
sterling (tarif 1989) et prevoit des investissements excedant 160 millions de 
livres sterling par an. L’actif est distribue en surface et en sous-sol sur une 
zone geographique couvrant 10,500 kilometres carres avec une population 
de 4 millions d’habitants. 

La solution choisie par la societe IT Southern consiste a exploiter une base 
de donnees d’informations geographiques (GIS, Geographical Information 
System). Le GIS a evolue depuis 1988 et son achevement est du pour 1995. 
Le GIS utilise des postes de travail SUN, des reseaux de transmission de 
donnees a large bande passante, des unites centrales ICL et une gamme de 
progiciels d’application. A terme, les bases de donnees associees au systeme 
GIS occuperont un volume de plus de 150 Giga-octets et seront reliees a 
I’unite centrale et aux serveurs SUN Microsystem. 

Utilisation des Techniques de Programmation Logique en Fonction du 
Temps a la gestion des mouvements de containers dans un port 
M. J. Perrett, ICL Strategic Systems, Bracknell, UK, p. 537 

Cet article traite des problemes de gestion de ressources au sein d’un terminal 
portuaire pour grands containers. II decrit un systeme developpe au terminal 
International de Hong-Kong (HIT), le plus important terminal prive pour 
containers au monde. Les techniques et outils utilises dans le developpement 
de ce systeme sont decrits ainsi que de Tutilisation d’un langage de pro¬ 
grammation logique en fonction du temps, CHIP. 

LOCATOR - Une base de connaissances au service de la clientele d’ICL 
G. W. Rouse, (formerly) ICL Customer Services, Stevenage, UK, p. 546 

Ce texte decrit la conception et - apres quelques faux departs -le developpe¬ 
ment d’un systeme de diagnostic rapide des causes vraisemblables de fautes 
dans les systemes informatiques. 

Le projet, desormais en exploitation, permet aux operateurs en contact 
telephonique avec les usagers de les interroger et de decider de la meilleure 
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fagon de traiter les appels, soit en conseillant immediatement le client quant 
a Taction corrective a adopter, soit, si un ingenieur doit intervenir, en 
s’assurant qu’il est bien qualifie pour resoudre le probleme en question et 
qu’il dispose de tout le materiel dont il aura vraisemblablement besoin. En 
conclusion figure un resume des avantages pratiques du systeme. 


Conception de TInterface Homme-Machine d’un Editeur Graphique: Une 
Etude de Cas de Conception axte sur les Utilisateurs 
K. Lewis, Standard Telecommunication Laboratories, Harlow, Essex, UKy 
p. 554 

Cet article decrit le developpement de Tinterface homme-machine d’un 
editeur pour base de connaissances hierarchisees. Le systeme expert existant 
manquait d’un support adequat pour Telaboration et la maintenance de 
structures arborescentes. On nous a demande de concevoir un outil permett- 
ant la cosntruction, Tedition et la maintenance d’une grande structure 
arborescente. 

Les exigences du client portaient sur un editeur graphique sophistique, 
pouvant etre utilise par des utilisateurs inexperimentes, mais il existait 
certaines opinions et aspirations divergentes. La complexite des exigences 
suggerait Telaboration rapide et iterative d’un prototype d’interface et son 
evaluation. La conception de Tinterface fut selectionnee a partir d’un 
ensemble d’alternatives, en cooperation avec les utilisateurs de systeme. La 
conception finale fut affinee a partir de Toption choisie. 

Pour conclure, nous pensons que Telaboration rapide el iterative d’alterna¬ 
tives d’interface, accompagnee de Tevaluation officieuse de Tutilisateur final, 
facilite Tacceptation du client et la construction d’un systeme utilisable. 
L’outil resultant est utilise depuis plus d’un an et a regu Tentiere acceptation 
de ses utilisateurs sur plusieurs sites. 


X/Open:Une Ascension Irresistible 

C. B. Taylor, Systems Integration Division, ICL, Bracknell, UK, p. 565 

Un article dans le numero de Novembre 1987 du “ICL Technical Journal” 
decrivait la creation du X/Open Group en 1984 et son developpement et ses 
realisations au cours des trois premieres annees. Ce nouvel article s’attache 
aux trois annees suivantes, au cours desquelles le label X/Open (tm) s’est 
developpe pour impliquer la plupart des membres importants de Tindustrie 
mondiale des technologies de Tinformation, et est devenu une grande force 
de progres et d’unification pour le succes des Systemes Ouverts. 


Architectures de Processeurs dedies a la Gestion de Bases de Donnees 
K, E Wong, European Computer Research Centre, Munich, Germany, p. 584 

La recherche en matiere de processeurs dedies a la gestion de bases de 
donnees a toujours ete tres active depuis les annees 70; cependant, peu de 
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projets ont ete convertis en produits commerciaux. Cet article presente les 
architectures de plusieurs processeurs - deja commercialises ou en cours 
d’etude - dedies a la gestion de bases de donnees. Etant donne la rapidite 
des progres realises en matiere de technologie de logiciel et de materiel, 
certaines personnes pensaient que les machines a base de donnees n’etaient 
pas rentables. Cette opinion ne fait pas Tunanimite: au vu du succes de 
certaines machines a base de donnees deja commercialisees, il est demontre 
que la machine a base de donnees est utile, surtout pour les utilisateurs de 
grandes bases de donnees qui travaillent sur de vastes bases contenant des 
gigabytes d’informations. De plus, a partir de I’etude realisee sur les 
machines deja commercialisees, les facteurs d’influence sur I’acceptation 
d’une machine a base de donnees sont identifies. Ceux-ci peuvent influencer 
la conception des futures machines. A partir de la revision sur les prototypes 
de recherche, les tendances au sein de I’architecture des machines a base de 
donnees sont soulignees. 


Simulation Informatique pour le Developpement Efficace des Technologies 
a base de Silicium 

P. Mole, Standard Telecommunication Laboratories, Harlow, Essex, UK, 
p. 614 

Le cout tres eleve de I’equipement necessaire a la fabrication de circuits 
integres modernes necessite que le temps de developpement pour chaque 
generation de technologie soit le plus court possible. La simulation 
informatique est desormais utilisee pour assister ce developpement et STL 
a ete impliquee dans les programmes de collaboration Alvey et ESPRIT 
pour faire progresser de telles methodes. 

Le modelage est applique a deux classes de probleme: les etapes de traitement 
qui menent a la diffusion de I’element dopant dans le silicium et a I’expansion 
des oxydes de surface, et les performances electriques du dispositif. Ces deux 
problemes engendrent des ensembles conjugues d’equations differentielles 
partielles non lineaires qui peuvent etre resolues par adaptation des tech¬ 
niques numeriques souvent utilisees dans d’autres secteurs d’ingenierie, telles 
que la methode des elements finis. La resolution du probleme sur des sections 
bi-dimensionnelles a travers les dispositifs, conduit a de larges ensembles 
d’equations algebriques [4.000-12.000] qui ont necessite le developpement 
de techniques de matrices eparses efficaces pour leur resolution. Pour obtenir 
la precision requise, il est necessaire de choisir le maillage avec le plus grand 
soin ainsi que la representation des equations sur le maillage, afin d’obtenir 
une solution precise et stable. 

Ces techniques de modelage ont ete utilisees de maniere extensive par STC 
pour assistance aux developpements technologiques. Les applications 
actuelles incluent le developpement de la technique bipolaire dans le cadre 
du repetiteur a fibre optique Gbit et le developpement des technologies 
CMOS a 1 et 0,7 pm. 
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L’utilisation de la Methodologie Structuree Ward et Mellor pour la concep¬ 
tion d’un systeme temps reel complexe. 13/12/1990 

R. Whetton, M. Jones and Don Murray, ICL Computer Products Division, 
West Gorton, Manchester, UK, p. 634 

Le systeme temps reel decrit correspond au logiciel de gestion de TOrdinateur 
de Support Nodal du Noeud SX qui a ete decrit dans la precedente parution 
du Journal. L’objectif des concepteurs du projet -connu dans les mileux 
concernes comme ISA (Initialisation and Support Application) - fut de 
produire un systeme temps reel d’une meilleure qualite et, simultanement, 
d’augmenter leur propre productivite. Ces objectifs ont ete atteints grace a 
I’utilisation de la Methodologie Structuree de Ward et Mellor, assistee par 
I’outil de saisie Excelerator de conception brevetee. 

L’historique de ISA est rappele et les raisons pour lesquelles la methodologie 
a ete choisie et la maniere dont elle a ete introduite dans le projet font I’objet 
d’une explication. Les phases d’analyse et de conception du projet sont 
ensuite decrites, en portant I’accent sur les caracteristiques Ward et Mellor 
employees et I’utilisation de I’Excelerator. Pour finir, quelques conclusions 
d’ordre general sont exprimees, suite au succes remporte grace a I’utilisation 
de la methodologie et de Toutil. 
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Zusammenfassungen 


ISDN 

Vorwort von Mr R, D, Smith, Director Financial Services Business & Network 
Industry, ICL, London, UK 

Einfuhrung in die technischen Merkmale von ISDN 

M. Orange, ICL Networks Applications IT services, Velizy, France^ p. 451 

Die Haupteigenschaft eines “Integrated Services Digital Network” ist die 
Bereitstellung einer breiten Palette von Funktionen fiir Telephonie- und 
Nicht-Telephonie-Anwendungen innerhalb eines einzigen Netzwerkes. 

Es ist das Ziel dieser Abhandlung, diese kurze vom C.C.I.T.T. gegebenen 
Definition zu erlautern. Es werden zuerst die Grundmerkmale von ISDN 
beschrieben und dann ein Uberblick fiber die ISDN-Protokolle fur die 
“Basic Rate” Schnittstelle gegeben. 

ISDN in Frankreich: NUMERIS und sein Markt 

L. Calot und A. Soiracopoulos, ICL Networks Applications IT services, Velizy, 
France, p. 468 

Diese Abhandlung gibt einen Uberblick iiber das franzosische ISDN, NUM¬ 
ERIS genannt, und seinen Markt. Zunachst wird der technische Hintergrund 
von NUMERIS, die verschiedenen Vorlaufer von ISDN-Kommunika- 
tionsnetzen und die Implementierung von NUMERIS beschrieben. 

Da ISDN eine grosse Veranderung der Telekommunikations-Vernetzung 
darstellt und ein sehr subtiles Marketing voraussetzt, wird dann die von 
France Telecom ausgearbeitete Strategic und abschliessend die angebotenen 
ISDN-Terminals und -Anwendungen erlautert. 


Die Telecom-Szene in Spanien, 

J, Larraz, ICL Madrid, Spain, p. 493 

Spanien muss fiir die Herausforderung von 1992 bereit sein. Sowohl 
Anwender als auch Lieferanten scheinen zu erwarten, dass der Einsatz und 
die Entwicklung von Kommunikations-Produkten dieses Jahr erhoht 
werden. Der ISDN-Dienst ist jedoch das grosste Fragezeichen .... 

Zukiinftige ISDN-Anwendungen in der Informations Technologic 
A, R. Fuller, ICL Networks Industry, Windsor, UK, p. 501 
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Diese Abhandlung untersucht zuerst die speziellen Vorteile der ISDN-Kom- 
munikation fiir Computerbenutzer. Sie deutet den Spielraum an, den ISDN 
fur innovative Anwendungen bietet, insbesondere jene, deren Einsatz and- 
ernfalls schwierig oder zu teuer waren. 

Sie beschreibt dann anhand von Beispielen eine Art von ‘‘DeskTop Confer¬ 
encing”, welches von STC/ICL demonstriert wurde. Dies ist ein Multimedi- 
ensystem, das zwei oder mehreren Personen die Zusammenarbeit von 
entfernten Orten aus ermoglicht und sowohl Sprache als auch Bildiibertra- 
gung beniitzt, um z.B. Texte zu iiberarbeiten oder eine technische Konstruk- 
tion zu entwickeln. 

Die Abhandlung endet mit der Skizzierung einiger zukiinftigen Anwen¬ 
dungen, die durch ISDN ermoglicht werden. 

WEITERE ABHANDLUNGEN 

Ein Geographisches Informationssystem fur die Verwaltung der Vermogen- 
swerte einer grossen Wasserversorgung, 

C. E, H. Corbin, IT Southern Ltd., Brighton, Sussex, UK, p. 515 

Die Anhandlung beschreibt, wie mit Hilfe von Informations-technologie die 
Probleme gelost werden, die eine Wasserversorgungs AG. mit der Verwal¬ 
tung ihrer Vermogenswerte hat, deren gegen-wartiger Wert £2.649 Millionen 
betragen und die ein laufendes Kapital-Investitionsprogramm von iiber £160 
Millionen pro Jahr hat. Die Vermogenswerte befinden sich iiber und unter 
der Erde, uber eine geographische Flache von 10.500 Quadratkilometern 
verteilt, auf der eine Wohnbevolkerung von 4 Millionen lebt. 

Die gewahlte IT-Losing beniitzt ein geographisches Informations-system 
(GIS). GIS wurde seit 1988 laufend weiterentwickelt, und seine Fertigstel- 
lung ist fiir circa 1995 geplant. GIS verwendet SUN-Workstations, Breit- 
band-Datenubertragungsnetze, ICL Mainframes und eine Reihe von 
speziellen Anwendungspaketen. Bei Fertigstellung wird die GIS-Datenbank 
einen Umfang von iiber 150 Gigabyte haben und sowohl an den ICL- 
Mainframe als auch an die verteilten SUN Microsystem Server angebunden 
sein. 


Verwendung von “Constraint Logic” - Programmiertechniken bei der 
Planung eines Containerhafens. 

Af. J. Perrett, ICL Strategic Systems, Bracknell, UK, p. 537 

Diese Abhandlung beschaftigt sich mit dem Problem der Ressourcenverwal- 
tung eines grossen Container-Umschlagplatzes. Sie Beschreibt ein System, 
das am Hong Kong International Terminal (HOT) entwickelt wurde, dem 
grossten im Privatbesitz befindlichen Container-Umschlagplatz der Welt. 

Es werden die, bei der Entwicklung des Systems verwendeten Techniken 
und Werkzeuge erlautert, insbesondere die Verwendung von CHIP, eine 
“Constraint Logic” - Programmiersprache. 
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LOCATOR - Eine “Knowledge Engineering” - Anwendung fiir ICLs 
Kundendienst 

G. fV, Rouse, (ehemals) ICL (UK) Office Systems Services CS, Stevenage, 
p. 546 

Die Abhandlung beschreibt, wei ein System zur schnellen Diagnose der 
moglichen Ursachen bei Fehlern in Computersystemen, erarbeitet und nach 
einigen Ruckschlagen weiterentwickelt wurde. 

Der Plan ist nun in Betrieb und erlaubt es im telefonischen Kontakt mit 
den Anwendern, diese zu befragen und sofort zu entscheiden, wie der Kun- 
dendienstanruf am besten zu erledigen ist: entweder durch eine sofortige 
Beratung des Kunden uber die zu ergreifenden Abhilfemassnahmen, Oder 
wenn ein Technikerbesuch notwendig ist, zu gewahrleisten, dass dieser zur 
Losung des Problems auch qualifiziert ist und, dass er die wahrscheinlich 
benotigten Ersatzteile mit sich nimmt. Abschliessend werden die praktischen 
Vorteile dieses Systems zusammengefasst. 

Konstruktion des HCI fur einen grafischen “Knowledge Tree” Editor: Eine 

Fallstudie fur anwenderorientierte Entwicklung 

K. Lewis, STC Technology Ltd,, Harlow, Essex, UK, p. 554 

Die Abhandlung beschreibt die Entwicklung eines HCI (Human Computer 
Interface) fixr einen “Knowledge Tree” Editor. Dem bestehenden Experten- 
system fehlte die ausreichende Unterstiitzung zum Aufbau von “Knowledge 
Trees”, deren Erweiterung und Pflege. Wir wurden aufgefordert ein Werk- 
zeug zu entwickeln, das die Konstruktion, Anderung und Pflege eines grossen 
“Knowledge Trees” ermoglicht. 

Die Kundenanforderung nach einem leistungsfahigen Grafik-Editor, geeig- 
net zum Gebrauch durch unerfahrene Anwender, war durch unterschiedliche 
Meinungen und Erwartungen gepragt. Die Komplexitat der Anforderung 
verlangte die schnelle, iterative Entwicklung und Auswertung eines HCI- 
Prototyps. Der HCI-Entwurf wurde, durch Diskussionen mit potentiellen 
Anwendern, aus einer Anzahl von Alternativen ausgewahlt. Die endgultige 
Entwicklung wurde aus der gewahlten Option vervollstandigt. 

Wir schliessen daraus, da die schnelle, wiederholende Prototypen-Entwick- 
lung von HCI-Alternativen, zusammen mit einer informellen Auswertung 
durch Endbenutzer, die Konstruktion eines brauchbaren Systems und die 
Akzeptanz durch den Kunden erleichtert. Das resultierende Werkzeug ist 
seit liber einem Jahr in Gebrauch und hat vollstandige Akzeptanz durch 
seine Benutzer in mehreren Anwendungsorten gewonnen. 

X/OPEN - Ein Erfolg nach dem Anderen 

C. B. Taylor, ICL Systems Integration Division, Bracknell, UK, p. 565 

Ein Artikel in der Ausgabe vom November 1987 des Technical Journal 
beschrieb die Entstehung der X/OPEN-Gruppe im Jahre 1984 und ihr 
Wachstum und ihre Errungenschaften in den ersten drei Jahren. Dieser 
Artikel fiihrt die Geschichte durch die folgenden drei Jahre wei ter. In dieser 
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Zeit wuchs die X/OPEN-Gruppe, an der heute die meisten der weltweit 
grossten IT-Firmen teilnehmen und wurde zu einer sehr bedeutenden, trei- 
beden und vereinigenden Kraft des Erfoltes von offenen Systemen. 

Architektur von Datenbanksystemen 

K, E Wong, European Computer Research Centre, D8000 Munchen, Deutsch¬ 
land^ p. 584 

Die Forschung hat sich schon seit den 70er jahren sehr aktiv mit Datenbank¬ 
systemen beschaftigt; jedoch wurde nur eine geringe Anzahl der Forschungs- 
Prototypen zum kommerziellen Erfolg. In dieser Abhandlung wird die 
Architektur einer Anzahl von Forschungs- und kommerziell geniitzter 
Datenbanken beschrieben. Aufgrund der Entwicklungsfortschritte bei 
den Software- und Hardware-Technologien, glaubten einige, da Datenbank- 
systeme nicht kosteneffektiv seien. 

Diese Ansicht wird angezweifelt: der Erfolg einiger kommerziellen Daten- 
banksysteme beweist den Niitzen von Datenbanken, besonders fur Beniitzer, 
die mit sehr grossen Datenmengen von mehreren Gigabytes an Infor- 
mationen arbeiten. Des weiteren werden, aus der Studie iiber kommerzielle 
Datenbanken, die Faktoren identifizierte, die die Akzeptanz eines Daten- 
banksystems beeinflussen. Architekturen von Forschungs-Datenbanken sind 
ebenfalls wichtig. Sie konnen die Entwicklung zukiinftiger Systeme beein¬ 
flussen. Ausgehend von der Technologic einiger Forschungs-Prototypen 
werden Trends in der Datenbank-Architektur erlautert. 

Computer-Simulation fur die rationelle Entwicklung von Silizium-Techno- 
logien 

P. Mole, STC Technology Ltd., Harlow, Essex, UK., p. 614 

Die sehr hohen Investitionskosten, die fiir die Herstellung moderner integri- 
erter Schaltungen benotigt werden, machen es notwendig, da die Entwick- 
lungszeiten fiir die einzelnen Technologie-Generationen soweit wie moglich 
reduziert werden. Computer-Simulation wird heute dazu beniitzt, um diese 
Entwicklungen zu unterstiitzen, und STC war an den kooperativen Alvey- 
und ESPRIT-Programmen zur Weiterentwicklung dieser Methoden beteiligt. 

Modellierung wird auf zwei Problemklassen angewendet: die Verarbei- 
tungsschritte, die zur Diffusion von Dotierungsstoffen innerhalb des Sili- 
ziums und zum Wachstum von Oberflachenoxiden fiihren, und die elektrische 
Leistung der Schaltung. Beide verursachen gekoppelte Mengen nicht linearer 
partieller Differentialgleichungen, die durch die Anwendung numerischer 
Techniken gelost werden konnen, wie etwa die ‘‘Finite Element” Methode, 
die auch auf anderen technischen Gebieten weit verbreitet ist. Die Problemlo- 
sung von zweidimensionalen Schniten durch die Gerate resultiert in grosse 
Mengen von algebraischen Gleichungen (4.000-12.000), die die Entwicklung 
wirksamer Sparse Matrix-Techniken fur ihre Losung erforderten. Um die 
erforderliche Genauigkeit zu erhalten und eine stabile Losung zu erreichen, 
muss man vorsichtig sein, bei der Auswahl der Maschen und bei der Darstel- 
lung der Gleichungen auf den Maschen. 
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Diese Modelliertechniken wurden von STC umfassend zur Unterstiitzung 
von Technologie-Entwicklungen verwendet. Aktuelle Anwendungen 
umfassen die Entwicklung bipolarer Technologic fur Anwendung in Gbit- 
Glasfaser-Repeatern oder die Entwicklung von CMOS-Technologien von 1 
und 0,7 /zm. 

Der Gebrauch der strukturierten Methodologie nach Ward und Mellor fiir 
den Entwurf eines komplexen Echtzeitsystems. 

R, Whetton, M. Jones und Don Murray, ICL Computer Products Division, 
West Gorton, Manchester, UK, p. 634 

Das beschriebene Echtzeitsystem liefert die Software-Funktionalitat fiir den 
“Node Support Computer” des SX-Netzknotens, der in der vorigen Ausgabe 
des Journals beschrieben wurde. Das Projektziel der Entwickler -intern als 
ISA (Initialisation and Support Application) bekannt - war es, ein Echtzeit¬ 
system mit verbesserter Qualitat zu produzieren und gleichzeitig ihre eigene 
Produktivitat zu erhohen, Diese Ziele wurden erreicht, indem die struk- 
turierte Methodologie nach Ward und Mellor benutzt wurde, unterstiitzt 
durch das eigene Entwicklungswerkzeug EXCELERATOR. 

Der Hintergrund von ISA wird dargestellt, und die Griinde fiir die Auswahl 
der Methodologie, und wie sie in das Projekt eingefuhrt wurde, werden 
erlautert, wobei die verwendeten “Ward und Mellor” - Merkmale und der 
Gebrauch von EXCELERATOR betont werden. Abschliessend werden 
umfassende Ruckschlusse aus dem Erfolg gezogen, der sowohl durch den 
Gebrauch der Methodologie als auch des Entwicklungs-Werkzeuges erzielt 
wurde. 
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ISDN 



Foreword 


The topic of the following four papers the new Integrated Services Digital 
public Networks (ISDN), is a very interesting one for me because I’ve been 
involved in it for several years, trying to understand how information 
systems and the world’s networks will work together to change the computer 
and communication industries. 


I’ve come to believe the changes will be dramatic, and sooner than most 
people think. If I’m right, the 1990s will see a major market discontinuity. 
From 1995 at the latest, a large share of the new information systems 
business will be sold as services through the networks, instead of as customer 
premises computers. I don’t know how large a share, but it will be enough 
to change the computer business dramatically. 


A return to time sharing? Why would anybody do that? There is in fact a 
reason, a system theoretic one. 


The Personal Computer has shown us the beginning of what people really 
want a desktop device to do. And it’s been so different from the old DP 
systems that we’ve called it a revolution. 


But what’s really different about a PC? Isn’t it just a desktop version of a 
terminal connected to a mainframe? Is the computer itself different? No, it’s 
not even a very sophisticated processor. The operating system? No, DOS is 
rather primitive compared to VME. Its languages? Nothing new. What, 
then? 


One simple thing about a PC makes all the difference. The screen is close to 
the computer. And that proximity matters only because it means the link 
between them can be fast. All the amazing graphics that make PCs so useful 
are made possible by that bandwidth. Nothing else is fundamentally 
different. 


But with such bandwidth across the Public Switched Network, things will 
change. The computer can be remote from the user again, without losing 
any of the sophisticated presentation or user interface possibilities. This will 
open enormous scope for network-based services. 
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Basic rate ISDN is just the beginning, but an important beginning, because 
it’s an order of magnitude step, and because it’s here today. I’m very pleased 
the ICL Technical Journal is featuring it, and I hope you’ll be stimulated 
to see it’s impact on your field of interest. 

Robert D, Smith 

Director, ICL Networks Industry and Financial Services Business 
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Introduction to the technical 
characteristics of ISDN 


Marc Orange 

ICL Network Applications IT Services, Velizy, France 


Abstract 

“The main characteristic of an Integrated Services Digital Network 
is to provide, within a unique network, a wide range of possibilities 
in telephony and non-telephony applications”. 

The goal of this paper is to explain this short definition given by the 
C.C.l.T.T. It first describes the basic characteristics of ISDN, and then 
gives an overview of the ISDN protocols for the Basic Rate Interface. 


1 Introduction 

About the end of the 60’s, the arrival of the first electronic switches and 
then the time-division systems opened up a wide range of new applications 
in communications and computing. 

This offered new services to send and process voice, data, text and image 
according to differing needs of the customer. 

These services are usually offered through different interfaces with different 
characteristics and different bearer networks. For the handler of the network 
this implies some complications, such as compatibility and security between 
the networks, cost, etc. 

ISDN (Integrated Services Digital Network) offers integration of these 
different bearers and services, using digital techniques through a powerful 
set of international standards, and seems to be the solution for success and 
progress in telecommunications. 

The international aspect of the ISDN standards gives these services a univer¬ 
sal characteristic. This integration will give more support to the user: only 
one interface, whatever service used, one number, one order, one installation 
with the different terminals connected to a universal socket. 
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The configuration of Fig. 1 will become that of Fig. 2. ISDN was born 
about 10 years ago in research labs and is now being implemented in many 
countries, as specified by the CCITT (International Telegraph and Telephone 
Consultative Committee). 



Network 

Termination 


Fig. 2 The ISDN configuration: one interface for several services 
2 Basic characteristics of ISDN 

2.1 The OS! reference model 

The ISO (International Standardization Organisation) divided the set of 
functions concerning the communication services into 7 “functional layers” 
on the basis of the following main criteria: 

• homogeneity of the functions within one layer, 

• definition of layers between which interactions are as limited as possible, 

• restriction of the number of functional layers. 

Fig. 3 represents the 7 layers of the OSI model (Open System Interconnec¬ 
tion). The 3 lower layers refer to the functions necessary for ensuring the 
transfer of information between two terminals across a network. 

The 4 upper layers concern more closely the applications available to users. 
They describe the rules for information transfer, dialog, presentation etc... 
allowing applications to run between distant users. 
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Communication 

Service 



Physicai Medium 

Fig. 3 The OSI model with its 7 layers 

These layers are defined as follows: 

Layer 1 (physical layer) handles the physical aspects of the connection of 
the terminals to the communication lines: mechanical and electrical inter¬ 
faces and binary element exchange protocols. 

Layer 2 (data link layer) corresponds to the transfer of information over 
the communication lines; it usually contains detection and recovery mechan¬ 
isms against transmission and overflow errors. 

Layer 3 (network layer) ensures the establishment and release of commun¬ 
ication as well as the routing of user information across the network. It is 
the first layer to include the network (and routing) notion. 
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Layer 4 (transport layer) provides end-to-end monitoring of the transfer of 
information across the network. It is therefore particularly applicable to 
aspects such as the addressing of the ends, connection procedures, synchron¬ 
ization of the interchanges, and possibly error and flow control. 

Layer 5 (session layer) defines the organization of the interchanges and the 
structure of the dialog between applications. 

Layer 6 (presentation layer ) defines the syntax of the exchanged information. 
It also includes the mechanisms involved in the security of access to the 
information. 

Layer 7 (application layer) contains the common mechanisms which can be 
implemented for various services. The user accesses OSI services via this 
layer. 

2.2 CCITTISND Recommendations 

The CCITT Recommendations on the ISDN are set out in the Recommenda¬ 
tions of the I series: 


• 1.100 Series: General concepts, 

• 1.200 Series: Services, 

• 1.300 Series: Network aspects and functions, 

• 1.400 Series: User-network interfaces, 

• 1.500 Series: Internetwork interfaces, 

• 1.600 Series: Maintenance principles. 

Some of these Recommendations may be found under other references 

(X, Q, ...). 

For the User-network interfaces, 

• 1.410, 411, 412 are general descriptions, reference configurations and 
structures, 

• 1.420 concerns the Basic Rate Interface, pointing to 1.430, 1.440/441 
and 1.450/451, 

• 1.421 concerns the Primary Rate Interface, pointing to 1.431, 1.440/441 
and 1.450/451, 

• 1.430 defines the B.R.I. physical layer protocol, 

• 1.431 defines the P.R.I. physical layer protocol, 

• 1.440/441 defines the link layer protocol (called LAPD), 

• 1.450/451 defines the network layer protocol (called D protocol), 

• 1.460, 461, 462, 463, 464 define multiplexing, rate adaptation, interface 
conversion,... 
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2.3 ISDN Services 


The operator of an ISDN can offer two types of service (1.200 Series): 

• bearer services, offered by layer 3, which concern the rates and the 
transmission quality levels,...There is no guarantee of compatibility 
between the terminals in communication. 

• teleservices, which imply that the terminals use the same protocols in 
order to guarantee compatibility between them. Each of these types is 
divided into “basic services” and “supplementary services”. 

The CCITT has defined “attibutes” characterizing these services. 

Bearer services: 

• information transfer attributes: 

- information transfer mode: circuit or packet; 

- information transfer rate: 64 kb/s, 384 kb/s, 1536 kb/s, 1920 kb/s, or 
other; 

- information transfer capability: unrestricted digital, speech, audio 
3.1 kHz, audio 7 kHz, audio 15 kHz, video, or other; 

- structure: 8 kHz integrity, service data unit integrity, none; 

- communication set up: on demand, permanent, or reserved; 

- communication configuration: point-to-point, multipoint or 
broadcast; 

- symmetry: unidirectional, symmetrical bidirectional, or assymetrical 
bidirectional. 

• access attributes: 

- channel and rate: D (16 kb/s), D (64 kb/s), E (same as D), B (64 kb/ 
s), HO (384 kb/s), Hll (1536 kb/s), H12 (1920 kb/s), or other (these 
high rates concern the Primary Rate Interface); 

- signalling access protocol: 1.451, CCITT 7, 1.462 or other; 

- information access protocol: G.711, 1.460, 1.451, X.25 or other. 

• general attributes: 

- supplementary services (see further); 

- service quality; 

- interworking possibilities; 

- operational and commercial aspects. 

Teleservices: 

• low layer attributes 

- information transfer attributes (see bearer services); 

- access attributes (see bearer services). 

• high layer attributes 

- user information type: speech, sound, text, fax, videotex, video or 
other; 

- layer 4 protocol: X.224, T.70 or other; 

- layer 5 protocol: X.225, T.62 or other; 
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- layer 6 protocol: T.73, T.61, T.6, T.lOO or other; 

- resolution (if applicable): 200, 240, 300, 400 or other; 

- graphic mode (if applicable): alpha-mosaic, geometric, photographic 
or other. 

• general attributes 

- supplementary low and high layer attributes; 

- user-oriented quality of service; 

- interworking capabilities; 

- operational and commercial aspects. 

Supplementary services: 

• sub-addressing: enables a caller to select a particular terminal within an 
installation, adding 1 to 4 extra digits to the public installation number. 
On receiving a call, a terminal compares its own programmed S.A. (sub¬ 
address) to the incoming one, and accepts the call if there is matching. 
This service doesn’t require a network action, except for carrying 
through the S.A. 

• Direct Dialling In with designation numbers: this service is very much 
used in PABX (Private Automatic Branch eXchange) installations, 
where different suscriber numbers are grouped to the PABX, and the 
designation numbers (extracted from the called number) are used (by 
the PABX or the terminals) to select a particular terminal. 

• systematic call presentation: as the D channel is always available, it can 
report every incoming call to the user, even when the B channel resources 
are saturated. 

• user-to-user information: allows users to exchange small information 
blocks using signalling messages (via D channel). 

• to-and-fro facility: allows a user to switch between 2 communications 
by holding one or the other. 

• temporary call diversion: when a terminal receives a call, it can reroute 
it to another number in its response. This is different from the ‘‘call 
forwarding” because it is a call-by-call feature and it is handled by the 
terminal itself (no registration in the exchange). 

• call forwarding: allows the rerouting of all the incoming calls to another 
number (registered in the local exchange). 

• terminal portability: allows a user to suspend an active call and retrieve 
it on another compatible terminal within the same installation. 

• caller identification: allows a user to know the number of his caller. 

• charging indication: during a call, the user can know in real-time, the 
cost of its communication. The charging indication can be sent at the 
end of the call only. 

• restricted connection: enables outgoing calls to be restricted according 
the charge for the communication requested, or the number dialled. 

• one-way connection: enables the reservation of a certain number of B 
channels for outgoing calls or incoming calls. 

• priority connection: allows a user to initiate a call, even when the ex¬ 
change is overloaded. 
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• concealement of the caller's identity', when a user does not wish to be 
identified by his correspondant. 

• malicious call identification: when a user wishes the network to keep 
track of the caller’s identity (for legal proceedings). 

• itemized hilling: allows a user to have a detailled bill for all or part of 
his communications. 

2.4 Functional groups and reference points 


The CCITT has defined certain functional groups and reference points 
designating the boundaries between these groups. Fig. 4 gives the usual 
representation of them. 



Fig. 4 The functional groups and reference points defined by the CCITT 

• The Terminal Equipment (TE) whose access to the network is at the 
reference point S if it is a native ISDN terminal (TEl), or at the reference 
point R if it is a terminal (TE2) conforming to existing interfaces (V or 
X Series) using a Terminal Adapter R-^S (TA). 

• The Network Termination 2 (NT2) which handles user internal functions 
(a PABX is a NT2). The access to the network is at reference point T. 
This group may be omitted; in this case, S and T reference points 
coincide. 

• The Network Termination 1 (NTl) which controls layer 1 functions 
(power supply, frame multiplexing,...). This group is linked to the Line 
Termination (LT), which is part of the network, through the reference 
point U. The output of the LT (towards the switching) is at point V. 

3 The protocols at the S or T reference points for the Basic Rate Interface 

At the S and T reference points, two types of interface are defined: the Basic 

Rate Interface, and the Primary Rate Intreface. This paper describes only 

the B.R.I. which is the smallest and the most commonly used for terminals. 

The P.R.I. is more used for PABX (Private Automatic Branch eXchange). 

The main difference between these two interfaces is at layer 1; layers 2 and 

3 described below are common to both interfaces. 
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3.1 General aspects 


At the S/T interface, the total bit rate is 192 Kbits/s full duplex. This rate 
is demultiplexed, into two 64 Kbits/s B channels and one 16 Kbits/s D 
channel (see Fig. 5). 



Fig. 5 At the S/T interface, 2 B channels and 1 D channel are available and shared by 
the terminals (TEs) 


The D channel is always available for the terminals and has two main 
functions: signalling and information transmission. To establish a connection 
between two terminals, there is first a dialog (signalling) in the D channel 
to set up the call and describe the nature of it. 

After that, the two terminals can exchange information through one of the 
B channels or through the D channel itself (information transmission). To 
release the transmission, the D channel is used again (signalling). 

The protocol architecture in the D channel conforms to the OSI model 
(introduced above). 

A B channel could be considered as a pair of wires (dynamically connected 
and disconnected with D signalling), in which the network does not intervene 
except for the full duplex bit-by-bit transmission. It is the terminals’ choice 
to use a particular protocol to understand one another. 

In fact, layer 1 is common for the B and D channels. Fig. 6 gives a protocol 
implementation example in a data terminal. 

3.2 The physical layer (1.430) 

Layer 1 offers the following services: 

• transmission capability (in D and B channels), 

• activation and deactivation, 

• access to the D channel for signalling, 

• terminal power supply. 
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Data transfer In D 

Signalling 


X.25 data transfer 

t Transparent data transfer 


USER 

LAYERS 

LAYER 2 

LAYER 1 



ilM ISDN protocol 

Fig. 6 A protocol implementation example: 

Signalling in D (mandatory), X25 in D and B1, transparent transfer in B2 


It may use point-to-point or point-to-multipoint configuration. The physical 
bearer requires 4 pairs of wires, in which one pair is used for the NT to 
TEs direction, and one for the TEs to NT direction. The 2 other pairs may 
be used for power supply. 

Each terminal retrieves the 192 kHz clock from the incoming bit stream 
(from the NT), and uses it to transmit. The bits are contained in consecutive 
48-bit frames, represented in Fig. 7. 

In the TE to NT direction, the frame contains: 

• the frame lock (F) bit with its DC balance bit (L), 

• two B1 bytes with one DC balance bit each, 

• two B2 bytes with one DC balance bit each, 

• four D bits with one DC balance bit each, 

• the auxiliary frame lock bit (Fa) with its DC balance bit. 

In the NT to TE direction, the frame contains: 

• the frame lock (F) bit with its DC balance bit (L), 

• two B1 bytes, 

• two B2 bytes, 

• four D bits. 
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48 bits, 0.25 ms 


2 bits shift 


DLF L 


I 


NT->TE 

1 . 




TE->NT 



F: frame lock bit 


N: -not Fa 


L: DC balance bit B1: B1 channel bits 

D: D channel bit B2: B2 channel bits 

E: echo channel bit A; activation bit 

Fa: auxiliary frame lock bit S: 0 (further study) 

M; multiframe bit 

Fig. 7 Frame structure at S and T reference points 

• four echo bits (E), in which the NT puts the value of the preceeding D 
bit received from the terminals, 

• the activation bit (A), 

• the auxiliary frame lock bit (Fa) and the associated N bit, 

• the multiframe bit (M), 

• one unused bit (S), 

• one DC frame balance bit (F). 


The bits are coded in a pseudo-tristate scheme. AM’ produces no signal, 
while a ‘0’ is alternately coded as a positive or a negative pulse. Within a 
bit sequence (one or more bits long), the number of zeros may be even or 
odd. 

bits 0 1 0 0 1 1 0 0 0 

coding 

polarity + - + - + - 

Fig. 8 The pseudo tristate scheme: no signal for "1” bits, alternated polarity pulses for 
“0” bits 

If it is even, the number of positive pulses equals the number of negative 
pulses. As the pulses have the same duration, the continuous (DC) compon¬ 
ent of the sequence is nil. 
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If it is odd, supposing that the first pulse is negative, the latest one is also 
negative and creates a negative continuous component. An additional posit¬ 
ive zero, appended to the sequence, will set the continuous component to 
nil. This bit is called “DC balance bit”. 

In the NT to TE direction, since the NT alone is to transmit, there is one 
DC balance bit following the frame lock bit (F), and another one balancing 
the rest of the 48 bits frame. In the TE to NT direction, since the frame is 
the result of transmission of sections by different terminals, each section is 
balanced individually. 

The frame lock bit (F) is a positively coded ‘O’, violating the rule of pulse 
alternation. It is immediately followed by a DC balance bit. But this violation 
has to be compensated by another violation. This is done by the first 
following ‘0’ (negatively coded). This ‘0’ may be one B1 bit, the E bit, the 
D bit, or the Fa bit (this bit ensures that the second violation occurs at least 
14 bits after the frame lock bit). The DC balance bit is ‘0’ if there are an 
odd number of ‘O’s following the previous balance bit. 

The main characteristic of the D channel is that it is shared by the terminals 
(when in point-to-multipoint configuration). There is a protocol for handling 
priority and collision, ensuring a correct access for every terminal. 

This protocol uses the E channel, which is the echo of the D channel. When 
a terminal “sees” that the received E bit is different from the D bit it sent, 
it immediately stops transmitting. Once a terminal accesses the D channel, 
its priority becomes lower, giving more chance of success to the others in 
their turn. 

When there is no active communication on the interface, no signal is sent 
on the line (INFOO). This is the deactivated state. As soon as a TE wants 
to make an outgoing call, it starts transmitting a special pattern (‘00111111’, 
INFOl) until the NT responds with a 48-bit frame containing zero bits in 
B, D and E channels (INF02) and with the A bit equal to zero. This INF02, 
with its many zeros (ie many pulse edges) allows the TEs to synchronize 
their clocks, and so normal exchanges (48-bit frames as above) can start: 
TEs sending INF03 and NT sending INF04. 

Note that the A bit of INF04 equals 1. 

The same activating procedure occurs when the NT wants to deliver an 
incoming call to the terminals, except that there is no INFOl sent. 

In order to reduce power consumption, the NT (not the TE) can decide to 
go back to the deactivated state when there is no longer an active call: the 
NT stops sending signal (INFOO) and the TEs do the same. 
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0011010011101010001 


NT->TE 


NT->TE 


FL^ B1 _^EDAF^^_B2 

ru 

+- - +- +- +-+ 

^ ^ violation 

-DC balance 

Example 1 


0011111111111010001 
F L B1 E DAF^ _B2 



-1-violation 

DC balance 



Example 2 


Fig. 9 Two examples of alternation violation: 

-in example 1, the violation occurs in B1 

-in example 2, as B1, E, D and A are only "1” bits, the violation occurs in Fa (the 
14th bit of the frame) 


3.3 The data link protocol (1.4401441 or 0920/921) 

The layer 2 protocol in the D channel, usually called LAPD (Link Access 
Protocol in D channel), ensures: 
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• the setting up and releasing of one or more data links between the NT 
and the terminals. The distinction between the links is made by an 
identifier contained in each frame, 

• the bounding and alignment of layer 2 frames (HDLC frames), 

• the sequencing of the frames through a link, 

• error detection and recovery (if possible), 

• flow control. 

The LAPD is very similar to HDLC (High-level Data Link Control) but it 
is not compatible. 

Fig. 10 gives the frame structure. The Flag byte (‘01111110’) is the frame 
delimiter. 


[Flag 

Address 

Command 

Information [ FQS 

Flag] 


Fig. 10 The layer 2 frame structure in D channel 


The Address field (see Fig. 11) contains two bytes and permits identification 
of the destination for a command frame or the origin of a response frame. 
It has the following form: 


8 7 6 5 4 3 2 1 


SAPI 

C/R 

EA- 

TEI 

EA- 


Fig. 11 The address field: 

-the first byte contains 6 bits for SAPI, one bit for C/R (Command/Response), one 
for EA (Extension of Address = 0) 

-the second byte contains 7 bits for TEI and one bit for EA ( = 1, meaning "end of 
address field”) 

The SAPI (Service Access Point Identifier) and the TEI (Terminal End point 
Identifier) have a distinct value on a data link.The SAPI is used to identify 
a particular service point (in the terminal or the network) and the TEI 
identifies an end point in this service point. 

The SAPI values are: 

• 0 for a call control link, 

• 16 for an X25 packet switched link, 

• 63 for a management link. 

The SAPI value is chosen by the terminal, according the service it wants to 
use. 
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The TEI values are: 

• 0 to 63 for non automatic TEI assignment equipment, 

• 64 to 126 for automatic TEI assignment equipment, 

• 127 for broadcast data link. 

Some equipments can negotiate automatically (with the NT) their TEI 
values, while others can only propose a programmed value. The negotiation 
uses frames with a SAPI equal to 63 and a TEI equal to 127: 

• The TE sends an “identity request” with a TEI value (127 for automatic 
assignment TE, programmed value for other). 

• The NT replies with an “identity assigned” with the assigned (or ac¬ 
cepted) TEI value, or with an “identity refused”. 

The Command field may be one or two bytes: 

• one byte for the mode with no acknowledgement, or for the frames with 
no sequence number, 

• two bytes for the sequenced frames in multi-frame mode. 

The Information field, if present, contains information bytes used by the 
addressed service point. It is present in frames (UI) requiring no acknow¬ 
ledgement, often used for broadcasting (for example, on an incoming call), 
or in acknowledged frames (for point-to-point connections). 

The ECS (Frame Control Sequence) permits verification of the quality of a 
received frame. 

Each link is handled in a similar way to HDLC protocol, with I (Info) 
frames, S (Supervisory) frames and U (Unumbered) frames. The main 
differences between LAPD and HDLC are: 

• LAPD handles link multiplexing, broadcast data links, unacknowledged 
frame transfers, permanent link supervision and TEI management. 

• LAPD does not handle FRMR and TEST frames. 

3.4 The call control protocol (1.4501451 or 0930/931) 

Call control is at level 3 of the OSI model, and uses the call control link 
(SAPI value is 0, see layer 2). Its main function is to set up, control and 
release the B channels. The messages handled by the protocol are: 

• during the call setting up: ALERTING, CALL PROCEEDING, CON¬ 
NECTION, SETUP,... 

• during the call active phase: SUSPEND, RESUME,... 

• during the call releasing: DISCONNECTION, RELEASE,... 

• others: INFORMATION, STATUS,... 
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Fig. 12 is an example of the establishment and release of a call: The terminal 
X calls an ISDN subscriber where there are two terminals (Y and Z) ready 
to answer. Z takes the call and Y is released. 


TERM. X TERM. Z 



Terminal X sends a SETUP message, including bearer service description, 
destination address, etc... 

After having controlled the SETUP, the network sends it towards the 
destination and acknowledges X with a CALL PROCEEDING. When the 
SETUP arrives in the destination area, it is received by both Y and Z 
(broadcast feature), that ring and acknowledge with an ALERTING (which 
is sent back to X). At this stage, both Y and Z are ringing and displaying 
the caller’s address, and X sounds a ringing tone. 

When Z is picked up, it sends a CONNECTION. Then the network transmits 
the CONNECTION to X, acknowledges Z with a CONNECTION ACK, 
and advises Y that it is no longer involved in this call (with a RELEASE 
message which Y acknowledges with RELEASE COMPLETE). 

X sends CONNECTION ACK, and one full duplex B channel is available 
for the data transfer between X and Z (for a voice call, voice is digitized). 

Once the data exchanges have finished, Z (it may be X) sends DISCONNEC¬ 
TION that the network transmits to X, and the call is released with a 
RELEASE/RELEASE COMPLETE on each side. 

As the D channel is always available, it is still possible for either terminal, 
when one B channel is busy, to set up another call and establish the other 


ICL Technical Journal May 1991 


465 




























B channel. After that, although both B channels are busy, it still can receive 
an incoming call, hold one of the active communications, and take the 
incoming one. 

The ‘"hold” feature does not mean that 3 B channels can be handled at the 
same time, but that 2 active calls can use the same B channel alternately. 
In this case, the held call cannot permit data transfer. 

Of course, it is also possible to do X.25 communications via the D channel 
itself or send user-to-user information through the signalling exchanges. 

All the ISDN services described in 2.3 are activated using layer 3 protocol: 

• bearer services description is usually mandatory in layer 3 messages. 
For example, to set up a voice call, the SETUP message must specify 
at least: circuit, at 64 kb/s, for speech, on B channel, using 1451 for 
signalling and G711 for information transfer, etc. Supplementary bearer 
services are optional. 

• teleservices are usually optional. For example, to set up a data call, it 
is not mandatory to specify that X25 will be used for the information 
transfer through the B channel. Nevertheless, this may prevent a ter¬ 
minal which doesn’t handle this protocol from taking the incoming call. 

On the addressing capability, ISDN is very versatile: a terminal can be 
selected using one or more of the following features: 

• sub-addressing (supplementary service), with up to 4 digits, which pro¬ 
vides a way to select a particular terminal within an installation (incom¬ 
ing sub-address must match with the programmed sub-address of the 
terminal). 

• direct dialling in (supplementary service), similar to sub-addressing, 
except that the incoming digits are extracted by the network from the 
called address (this service is very often used in PABX installations), 

• low layer and high layer compatibility (teleservices), preventing for ex¬ 
ample, a telephone from ringing on an incoming data call. 

Furthermore, a terminal can use the user-to-user information for password 
control, or use the originating address to verify the caller identity. 

4 Conclusion 

This short description of ISDN techniques, although it is just an introduc¬ 
tion, illustrates the many advantages of this new way of communication, 
even for the private customer. 

The integration of the different existing networks, the continuous capability 
of signalling, the digital transmission quality (even for voice), the possibility 
of sharing one interface between several terminals, the large number of 
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services and selection features, the high bit rate for data transmission, 
etc...are all strong points of ISDN that have been obtained because of 
intelligent protocol specifications, taking into account the existing structures 
and protocols. 
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Abstract 

This paper gives an overview of the French ISDN, named NUMERIS, 
and its market. 

First, it describes the technical story of NUMERIS, the different pre- 
ISDN data communication networks and the implementation of 
NUMERIS. 

Then, as ISDN is a great change in communication networking, 
needing a very subtle marketing, this article goes through the strategy 
elaborated by France Telecom and concludes with the ISDN ter¬ 
minals and applications on offer. 


PART 1: THE FRENCH ISDN: NUMERIS 
1. The public network’s evolution towards ISDN 

1.1 Changes in the French telephone network 

During the 1970’s, the French telephone network went through a number 
of dramatic changes. In that decade, there was explosive growth in the 
number of telephone lines (reaching 24 million in 1981, up from 4 million 
in 1974), accompanied by significant changes in the telecommunications 
infrastructure. While the quantitative growth in the period was certainly 
spectacular, the underlying changes in network architecture were, perhaps, 
much more significant, especially in respect of the introduction of ISDN 
service. 

From early on, the French telecommunications policy was based on the 
digitization of the telephone network. France Telecom installed in 1970 the 
first fully digital central office switch. This started a major digitization effort 
that continues to this day, and has made the French telephone network the 
most digital in the industrialized world. 

According to (DICENET) the digitization stage of France Telecom’s net¬ 
work, in 1987, was as follows: 
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Local switching: 50 % 

Transit switching: 60 % 

Local Transmission: 70 % 

Long distance transmission: 50 % 


The charts of Fig. 1 and Fig. 2 show the evolution, past and projected of 
the network from the mid ’70s to 1995. 



Fig. 1 Switching digitization of the French telephone network 



Fig. 2 Transmission digitization of the French telephone network 
1.2 Network equipment 

In this section we present an overview of the switching and transmission 
equipment currently in use in the French telephone network. Basic under¬ 
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standing of this infrastructure is essential since the ISDN implementation 
depends heavily on the network infrastructure. 

1.2.1 Digital local switching Since 1970, France Telecom has been in¬ 
stalling exclusively digital, time division switches. The systems opted for 
were the Alcatel E lOB and E lOMT, derived from the Alcatel E 10 A series, 
introduced in 1970. Currently, 48 % of the 24 million telephone lines in 
France are connected to either E lOB or E lOMT. All other systems are 
gradually being phased out, while all updates concern only the newer 
switches. More than 600 switches of this type have been installed. The E lOB 
and E lOMT are second generation digital switches, capable of servicing 
areas of different levels of population density. 

Subscribers are connected through special units called CSE and URA2G, 
each capable of accepting up to 1000 connections. The advantage of these 
units is that they can be located outside the switch, at varying distances, 
thus allowing the addition of more capacity without installing more switches. 

1.2.2 Digital transit (long distance) switching Long distance switching 
is, currently, 60 % digital through the use of high capacity switches, namely 
the Alcatel E 12 and E lOMT, that are, progressively, replacing the older 
crossbar-type switches. 

1.2.3 Local transmission Local end transmission covers the part between 
a wiring unit, such as CSE, and the switch. This type of transmission is 
70 % digital, and the introduction of new techniques such as fibre optic 
transmission at 34 Mbits/s constantly increases this percentage. 

1.2.4 Long distance transmission The digitization of long distance trans¬ 
mission started much later than that of the local one, due to the lack of 
digital transmission systems competitive with analogue ones. Nevertheless, 
56 % of long distance transmission circuits are now digital. Long distance 
transmission uses the following types of support: 

• Coaxial cable, used for transmitting at 140 Mbits/s or at 4x140 
Mbits/s, 

• Radio frequency at 4-140 Mbits/s, 

• Fibre optic cable at 34 Mbits/s or 560 Mbits/s (monomode). 

1.3 CCITT No 7 signalling 

While the improvements described in the above section provide the transmis¬ 
sion and switching capacity necessary for implementing a generalized ISDN 
service, the adoption of CCITT No 7 signalling made available the means 
to implement the D protocol. 

The conventional telephone network uses the same communication channel 
for both signalling and information transfer. As a result, the signalling 
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possibilities are quite rudimentary, and limited to things like dialling, busy 
signal, ringing, etc. 

The implementation of D protocol requires substantial signalling capacities. 
CCITT No 7 is a protocol used to manage signalling in a separate “sema¬ 
phore” channel. 

While work on the definition of CCITT No 7 had started long before the 
definition of ISDN, the resulting signalling system is very well adapted to 
it, especially by allowing variable length messages. Implementing separate 
channel signalling necessitates the construction of a separate signalling 
network, superimposed on the information transfer one. Every local switch 
is associated with a signalling point (SP), which serves as the local CCITT 
No 7 handler. Signalling points are connected to signalling transfer points 
(STPs) through specialized links, running at 64 kbits/s. STPs route No 7 
messages to other STPs and can be associated with servers that provide 
additional information. 

The diagram of Fig. 3 illustrates the CCITT No 7 concept. 



Fig. 3 CCITT No 7 Network 

The introduction of CCITT No 7 was started in 1986, through upgrades of 
the Alcatel E 10 and E 12 systems, with the priority being placed on the 
long distance switches. By 1989, any two such systems could inter-commun- 
icate in message mode. The initial implementation of CCITT No 7 involved 
point-to-point connection between switches. A separate signalling network 
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was put in place in 1989, that will ultimately include 40 STPs, fully intercon¬ 
nected. The availability, at a national level, of No 7 signalling along with 
the digital transmission and switching infrastructure made possible the 
relatively early commercial introduction of ISDN in France. 

1.4 ISDN's beginnings in FRANCE: The RENAN project 

As we have seen in the previous sections, the network infrastructure has 
undergone extensive qualitative and quantitative improvements since the 
early 1970’s. These improvements led to the feasibility of offering an ISDN 
service, in the late 1980’s. The first attempt at a public ISDN service was 
that of the RENAN (RNIS des Entreprises pour les Nouvelles Applications 
Numeriques - Business ISDN for New Digital Applications) project. 

RENAN involved the connection to ISDN of about 1000 mainly small to 
medium sized businesses, located in the department of Cotes du Nord, in 
Brittany. 

The whole project was conducted by CNET, France Telecom’s research 
arm, and involved all the hardware and software upgrades to local switches, 
necessary in order to offer the service. 

RENAN evolved in December 1987 into the first-ever commercial ISDN 
service, covering, essentially, all of the departement, including the city of 
Rennes. 

The purpose of the project was to: 

• create a mini ISDN network, generalizable to the entire territory (Cotes 
du Nord; Brittany), 

• test the new ISDN services, 

• acquire the necessary feedback from the users, and test the ISDN 
marketing and commercial policy. 

The targeting of small businesses (or branch offices of larger enterprises) 
was dictated by the economy of the region, as well as by the fact that only 
basic rate (2B -h D) ISDN was available. 

2 France Telecom’s pre-ISDN data communications networks 

The development of the digital infrastructure of the network, in addition to 
improving voice services through more efficient transmission and switching, 
also gave rise to a number of data services. 

These digitization derivatives, known as “pre-ISDN”, were meant to provide 
data services on the telephone network, before the standard protocols were 
put in place. One important side effect of the pre-ISDN offer, was the 
development, by third parties, of a substantial number of applications that 
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were, subsequently, ported to full blown ISDN. At the same time, the users 
of, both, the services and the third party applications were “trained” on the 
possibilities opened by widely available public data networks. In general, 
such users were able to accept ISDN once it was put in place. 

Also, strictly speaking, the pre-ISDN offer includes the TRANSCOM, 
TRANSFIX and TRANSDYN services described below. We have however 
included TRANSPAC in our discussion, even though TRANSPAC is an 
entirely different network, because of its importance for ISDN in France, 
especially in respect of its integration with the telephone network. 

2 .1 TRANSFIX 

It consists of fixed point-to-point data links, available with a variety of 
interfaces and data rates. 

TRANSFIX offers 3 groups of options: 

• low speed, available in 24, 4-8, 9*6 and 19-2 kbps, with a V*24 interface 

• medium speed, in 48, 64 and 128 kbps with V-24, V I1, or X*21 interfaces 

• high speed, at 2 Mbps 

TRANSFIX has been available throughout France since 1980, even though 
its predecessor, TRANSMIC, had been operational as early as 1977. 

TRANSFIX lines are available 24 hours a day, and are fully backed up, i.e. 
continuity is guaranteed. 

The different TRANSFIX lines join the network through analogue or digital 
links and they are, subsequently, multiplexed into 2 Mbps PCM lines. 

2.2 TRANSDYN 

TRANSDYN, available since 1984, offers switched medium to high speed 
digital service, using both terrestrial and satellite links. The major difference 
between TRANSDYN and TRANSMIC lies in the switched nature of the 
link. An important TRANSDYN feature is that the line can be dynamically 
configured, at establishment time, to operate at different speeds. TRANS¬ 
DYN offers data links of up to 2 Mbps, as well as higher speed links used 
for video transmission. 

2.3 TRANSCOM 

TRANSCOM offers circuit switched digital links, at 64 kbits/s. It relies 
exclusively on the public telephone network, and presents a V-35 or X-21 
interface at the subscriber’s edge. 
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TRANSCOM, the immediate predecessor of Numeris, is a very important 
service, in that its characteristics are similar to those of ISDN, and that its 
implementation necessitated the solution of a number of technical problems 
which facilitated the subsequent introduction of ISDN. 

As we mentioned above, TRANSCOM relies on the public telephone net¬ 
work for transmission and switching. However, special interfacing hardware 
was put in place between the customers’ premises and the El0 series switches. 

At the customer’s premises, the X-21 or V'35 interface is provided in a 
special unit called RA (Regie d’abonne). RAs are connected, through 
72 kbits/s links, to multiplexing units called Digital Channel Connection 
Units (URCN in French), that are, subsequently, linked to the central office 
switch through 2 Mbits/s lines. 

The introduction of TRANSCOM has created a number of technical prob¬ 
lems, mainly stemming from the fact that the telephone network is not yet 
100 % digital. It was necessary to ensure that a TRANSCOM call was not 
routed through older, analogue long distance links. This was accomplished 
by assigning special numbers to TRANSCOM subscribers. This way, the 
switch can identify a TRANSCOM call once dialling is complete and route 
it through digital links. This technique is also used for ISDN calls, with the 
exception that a separate numbering plan is no longer necessary, since data 
calls can be differentiated from voice ones by examining the appropriate 
field in the layer 3 SETUP message. 

TRANSCOM has demonstrated the feasibility of providing a wide circuit 
switched 64 kbits/s service, and has prepared the users to accept ISDN, 
when it becomes available. 

2.4 TRANSPAC 

TRANSPAC, the French packet switching network, in operation since 1979, 
has 80,000 subscribers and is available throughout the whole country. It 
also serves as the backbone for a network of some 5,000,000 videotex 
terminals, the most extensive network of that type in the world. 

Clients can establish X25 virtual circuits at a variety of speeds, ranging from 
50 bps to 64 kbits/s, the 48-64 kbits/s class having been made available in 
July, 1990. 

TRANSPAC is used as the communications provider for a number of 
services such as videotext, X'400 electronic mail, EDI etc. It benefits from 
connections to other countries’ packet switching networks, via the Interna¬ 
tional Transit Node (INT) and InterPac. 

While Transpac uses some facilities of the existing telephone network, such 
as point-to-point lines, it is really an independent entity. Its importance for 
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ISDN lies in that, in addition to its accessibility from Numeris, described 
in the next section, it plays the role of an integrated network. 

By far the most important users of TRANSPAC are the millions of house¬ 
holds equipped with videotext terminals. The wide availability of videotext 
has benefited the introduction of ISDN in that it has introduced two 
important concepts. 

The first concept is that of a multi-service network. Videotext users are 
connected to TRANSPAC via the telephone network, through Videotext 
Access Points (VAPs). Thus, TRANSPAC access seems to be a natural 
extension to the ordinary telephone service, providing the final user with an 
integrated voice/data service. 

Secondly, the videotext network, as a provider of services, uses both the 
voice and data network, by exploiting the advantages of both, namely the 
global availability of the telephone, and the ability of TRANSPAC to handle 
sporadic traffic. In way, videotext becomes a multi-service network. ISDN 
is also a multi-service network that, in addition to its own services, is 
intended to integrate the different existing networks (see section 4). 

3 The implementation of Numeris 

3.1 Telephone network changes 

As mentioned in the previous section, the French telephone network relies, 
essentially, on the second generation digital switches, namely the Alcatel 
E lOB and E lOMT. While these switches, in conjunction with CCITT No 7, 
provide the raw transmission and switching capabilities necessary for 
offering ISDN services, a number of changes had to be made to the network 
infrastructure in order to implement ISDN. 

The main modifications of the network include the development of a new 
connection unit, the Digital Satellite Centre (DSC), used as an intermediary 
between the customers and the switch, as well as the (mostly software) 
updates of the switches themselves, in order to manage DSC and provide 
the new services. 

3.1.1 The Digital Satellite Centre DSC (in French CSN - Centre Satellite 
Numerique) is a universal wiring unit, used to connect both analogue and 
digital customers. It serves a dual purpose: provides ISDN lines and, through 
its universality and technical capabilities, minimizes the cost of providing 
new ISDN lines. 

DSC is compatible with the E 10 series switch, and connects to it using the 
CCITT No 7 protocol. It consists of a number of concentrating units, both 
local and remote, and a command and control unit that also provide the 
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interface to the switch. DSC’s general architecture is described in Fig. 4 
diagram. 
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Fig. 4 DSC architecture 

In the following 2 subsections we provide a short description of the concen¬ 
trating and control units included in the DSC. 

The concentrating unit: 

As shown in the figure 4, a DSC contains 2 types of concentrators: Distant 
ones, indicated as DDC (for distant digital concentrator), that can be located 
outside an DSC, and local ones (LDCs). In all, an DSC can support up to 
20 distant and/or local concentrating units. 

Distant concentrators are linked to the command unit of a DSC via 
2 Mbits/s or 704 kbits/s links. Their advantages are that they can be located 
close to small user populations and, thus, avoid the installation of DSCs, 
and that they generally decrease the length, and consequently the cost, of 
the subscriber’s line. 

Every concentrator is composed of a number of cards, to which subscribers’ 
lines are wired, and an interface to the control unit. This modular approach 
allows one to put the signalling, digitization, pre-processing, and concentra¬ 
tion logic on the cards, and, thus, dissociate the interface from the type and 
the number of lines attached to it. 

As mentioned in the previous section, the concentrator can support both 
analogue and digital (ISDN or TRANSCOM) customers. This is done 
through the use of a different card for each type of customer. The maximum 
number of cards, digital or analogue, supported by the concentrator is 16. 
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All cards share the resources of the concentrator, which include 1 to 4 
2 Mbits/s PCM lines, 1 signalling HDLC channel that communicates with 
the command unit, as well as a microprocessor and microcontroller. The 
capacity of the HDLC channel is doubled if more than 2 PCM lines are 
deployed. 

Analogue customers are connected to the TABA 16 card, which supports 
16 lines. Each card is, in fact, a motherboard containing up to 8 modules 
supporting 2 lines each. In addition to these modules, TABA 16 contains a 
controller, common to all modules, that assures timing and multiplexing as 
well as a processor and memory. The modular architecture of the TABA 16 
allows easy module replacement in case of failure, without disturbing the 
totality of the lines handled by the card. Each module contains a CODEC, 
in order to present a digital signal to the control unit. 

Digital (ISDN) subscribers are connected to the DSC via the TABN card. 
Each TABN card can support up to 8 ISDN lines. The functionalities of 
the TABN card include: 

• line interface, 

• B and D channel multiplexing/demultiplexing, 

• layer 2 of LAPD processing, 

• some layer 3 processing. 

The physical aspects of TABN are similar to those of TABA 16 and 8. 

Primary (30B-f-D) rate customers are connected to the TADP card, that 
offers functionalities similar to the TABA ones, with the exception that only 
one line is allowed per card. 

The control unit: 

The control unit of a DSC consists of a number of modules, that include: 

• 2 command units, of which one is in backup mode, 

• one unit for auxiliary control functions, 

• the interfaces to the switch. 

A command unit includes a processor and 1 Mbyte of memory and assures 
the exchange of information between the concentrators and the switch 
through special submodules, dedicated to each function and sharing the 
processor and memory. The command units hold a dialog with the switch 
through the CCITT No 7 protocol procedures. Auxiliary control functions 
include tone generation, pulse tone recognition and line testing. 

The switch interface, uses 2 to 16 PCM lines in order to exchange signalling 
and clock information with the switch. Its implementation differs depending 
on whether the DSC is a local or a remote one. 
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As the DSC can contain up to 20 concentrators, each supporting a maximum 
of 16 16-line cards, the maximum addressing capability of the DSC is 5120 
subscribers. A DSC is connected to the switch by a maximum of 16 
2 Mbits/s PCM lines. Since all control software is remotely loaded, the 
successive generations of ISDN described in the following section are easily 
installed throughout the country. 

3.1.2 New switch capabilities As mentioned in the previous section, most 
of the changes needed to provide ISDN service were incorporated in the 
new DSCs. However, a number of changes had to be made in the El 0-series 
switches. 

The co-existence of the analogue telephone network and Numeris, necessit¬ 
ates a great level of interaction between the two. The interconnection facility 
was implemented at the switch level. Thus the switch, will, for example, 
create a SETUP message for a Numeris customer receiving a call from a 
non-Numeris one, and will include the appropriate support service field to 
indicate the nature of the caller. 

While certain supplementary services do not require any switch involvement, 
but only concern end-to-end interaction, others, such as hold/reconnect, call 
redirection, temporary call diversion etc, necessitate some switch involve¬ 
ment, and, thus, modifications to the software of the switch. 

3.2 Numeris implementation schedule 

The introduction of ISDN in France was done in a series of successive steps, 
that began in early 1986. The following is a summary of this introduction: 

1986: Introduction of TRANSCOM, a pre-ISDN circuit-switched network, 
offering 64 Kbits/s data transmission, through an X21 interface. TRANS¬ 
COM had more than 500 subscribers by the end of 1987. 

1987: Beginning of installation of CCITT No 7 signalling throughout the 
telephone network. CCITT No 7 was strategic for the subsequent introduc¬ 
tion of ISDN. 

Installation of the synchronisation structure of the network, necessary for 
quality transmission. 

Beginning of the installation of Digital Satellite Centers. By the end of the 
year, a number of preliminary-version terminals became available, which 
included terminal adapters, telephones and NT Is 

A preliminary Numeris version became available in the Cotes du Nord 
department (RENAN). 

1988: Expansion of ISDN service to the city of Rennes and, subsequently 
to Paris, Neuilly and La Defence by the end of the year. TRANSPAC access, 
via the B channel, at rates ranging from 2-4 to 64 kbits/s. 
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1989: Commercial ISDN, including primary rate, was available in Lille, 
Paris, Lyon, Marseille and Rennes. 

1990: End of CCITT No 7 signalling installation. Every administrative zone 
(France is divided in 90 administration zones) is equipped with an DSC, 
which allows national ISDN coverage. 

The progressive introduction of Numeris necessitated different versions of 
switch and DSC software. There have been two versions to date, with a 
third one to be introduced shortly. 

3.3 Numeris Services 

In this section, we present the services offered by Numeris, and their avail¬ 
ability in each of its different versions. 

These services were introduced in the article “Introduction to the technical 
characteristics of ISDN” in this issue (Orange 1991). 

The services offered by ISDN belong to three categories: 

• bearer services, 

• teleservices, 

• supplementary services. 

3.3.1 Bearer Services Numeris offers 2 types of bearer services, that relate 
to the possibilities offered by a B-channel connection: 

• Transparent, switched B-Channel (CCBT). This is a point-to-point, 
circuit switched connection at 64 kbits/s, established on demand, and 
with a guaranteed end-to-end digital connection (TRANSCOM-style). 
Such a service is normally used for data transmission. 

• Non-Transparent B channel (CCBNT). Similar to the transparent one, 
with the exception that the connection may pass through non-digital 
circuits. It is meant to provide voice transmission. 

In addition to the 2 fundamental services above, available in the VN2 
version of Numeris, VN3 will offer a number of other services that will 
include: 

• X25 packet switching in the D channel 

• a small volume, secure data transmission service, in the D channel, the 
purpose of which is remote action and control. 

• access to the telex network, via the D channel. 

3.3.2 Supplementary Services The supplementary services specified by 
CCITT were presented in (Orange 1991). Here we present the services 


ICL Technical Journal May 1991 


479 


actually implemented in the VNl and VN2 versions of the network, along 
with a short description of each service. 

VNl and VN2’s set of standard supplementary services include: 

1 Suh-addressing. This allows a Numeris customer to add 1-4 extra digits 
to the called address. That enables the selection of a particular terminal 
(programmed with the same sub-address) within the called installation. The 
sub-address’s interpretation is up to the terminals, since it is transparently 
carried by the network. 

2 Caller identification. This allows a terminal receiving a SETUP message 
to know the calling number, by examining a field in the message that includes 
this number, along with an (optional) sub address. While the caller identi¬ 
fication is possible even for analogue callers, it is restricted to ISDN-to- 
ISDN calls for legal reasons. 

3 Suspend!Resume., This supplementary service allows a subscriber to 
suspend a voice communication, and resume it up to 3 minutes later. It is 
meant to permit terminal portability. 

In addition to the above services, the following are provided at additional 
charge (either on a call-by-call or a subscription basis): 

4 User-to-user messaging. A user is allowed to include an information field 
of a length up to 32 octets, in setting up and releasing call messages. This 
field is transparent to the network, and is charged on a call-by-call basis. It 
allows a user to send a message on another ISDN terminal (useful for 
passwording, or personal messaging). 

5 Direct Inward Dialling (DID). It consists of allocating to the subscriber 
a part of the national numbering plan, and of transmitting the last 4 digits 
of the called number in a separate field. On receiving these 4 digits, the 
called party can select a particular terminal to present the call. This feature 
is commonly used by PABXs (Private Automatic Branch Exchanges). 

It is charged on a subscription basis, depending on the number of telephone 
numbers attributed to the subscriber. 

It allows direct selection of an entity (terminal, person, service) inside an 
ISDN installation. 

6 B Channel specialisation. It specifies a number of channels as outbound 
or inbound only. It is charged on a subscription basis. 

7 Restricted connection. Allows restricting outgoing calls depending on the 
number selected, or the communication’s cost. 

8 Calling number identification restriction. It offers the possibility of not 
including the calling number field in a SETUP message when not wished. 
It is available on subscription, and concerns the whole installation at the 
subscriber’s site. This service is available for protection of civil liberties. 
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9 Real time charge information. Informs the caller in ‘real time’ of the units 
spent during a connection, by sending a FACILITY message every time a 
unit is consumed. It can be charged either on a subscription or a call by 
call basis. 

10 Total cost information. It informs the caller of the total communication 
cost, in units, in a special field of the RELEASE message. Charged on a 
subscription basis. 

11 Call forwarding: Allows the user to forward the whole installation to 
another number of the national numbering plan. The forwarding is done at 
the switch level. Charged on a subscription basis. 

12 Temporary call diversion. A terminal can divert a call towards a different 
number, upon reception of the SETUP message. It differs from call for¬ 
warding in that it is done and charged on a call-by-call basis. 

13 Itemized hilling. Supplied on a subscription basis, provides details of 
each long distance call made along with the bi-monthly bill. 

14 Double call. Allows calling another number while another call is in 
progress. The original call is, automatically, placed on hold. 

15 Call alternation. It permits alternating between a held and an active 
call. 

3.3.3 Teleservices The teleservices defined in VN1-VN2 are: 

• group 111 fax on a non-transparent (CCBNT) B-channel, 

• videotext-teletext on a CCBNT channel, 

• X-25 on a B channel, 

• group IV fax on a transparent (CCBT) B channel. 

3.4 Network Equipment offered by France Telecom 

France Telecom’s standard end-user equipment offer contains both network 
terminations and terminal equipment (see the description of these equipment 
in Orange, 1991). 

The user can rent or buy these equipments from France Telecom, or buy 
them directly from the manufacturers. Details of the market offer are given 
in Part 2 Ch.4.2. 

3.4.1 Network terminations There are two types of network termination 
currently available. The basic one, that requires one basic rate access, is 
called unique bus network termination and essentially comprises an NT2 
and a bus similar to the one described in (Orange, 1991). The bus connects 
up to 8 terminals. 

This type of network termination allows internal inter-terminal communica¬ 
tion, as well as Direct Inward Dialling (DID). It also processes locally a 
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number of supplementary services, thus playing the role of a rudimentary 
PABX. 

The second type of network termination is a multi-bus one. On the network 
side, there are 1 -6 basic rate accesses, while on the user side several busses 
are allowed in a star configuration. In addition to the supplementary services 
that are processed locally, ie without the intervention of a switch, the 
network terminations are capable of offering a number of services which 
are not available in the public network, such as 3-way conference (voice 
only), call waiting and call transfer. 

3.4.2 Terminal equipment available The standard terminal offer includes 
telephone and adaptor terminals (allowing connection of a terminal to 
ISDN). A telephone terminal includes a microprocessor, memory and the 
SO circuitry that allows it to connect to a ISDN bus. 

In addition to the usual functionalities of an office hands-free telephone, it 
contains features, implemented in software, permitting use of supplementary 
services of ISDN, such as a mini-telephone directory, a facility to send user- 
to-user messages, a small database containing recent call information etc. 

Among the first adaptors to be developed were the X21/S and V35/S ones, 
in order to allow Numeris to connect to equipment previously connected to 
the TRANSCOM network. In addition to these the following adaptors are 
available: 

• analogue/SO (ISDN interface) for modems, telephones, fax machines 
etc, 

• X25/S0, 

• V24/S0. 

4 Numeris and the existing networks 

As we have seen in section 2, a number of data communication networks 
existed before ISDN, namely TRANSCOM, TRANSPAC, TRANSMIC 
and TRANSDYN, in addition to the telephone and telex networks. These 
networks, while independent of each other, were already able to interconnect, 
through gateways. For example, a gateway connects the telex and TRANS¬ 
PAC networks, and PADs (packet assemblers/disassemblers) allow telephone 
subscribers to connect to TRANSPAC. 

In section 3, we briefly mentioned the facilities, existing or envisaged, used 
to provide connectivity between Numeris and the telex (through the D 
channel) and TRANSPAC networks. 

A Numeris subscriber can, in this way, gain access to all the services (such 
as X400 electronic mail, on-line databases, videotex etc) available through 
TRANSPAC. 
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While TRANSCOM will be eventually phased out, since it has now become 
redundant, TRANSMIC, TRANSDYN, and TRANSPAC will remain in 
place. These networks are not directly competitive with ISDN. 

Numeris, as we mentioned in section 1, will serve as a “backbone” network 
offering a basic set of services (switched voice and data) and, at the same 
time, access to more specialized networks, such as TRANSPAC (see Fig. 5). 


Telephone 

Videotext 

Teletext 

CPU 

LAN 


ISDN 

(TELEPHONE + TRANSCOM) 




TRANSPAC - 




PABX 

FAX 

Cluster Controller 


Fig. 5 ISDN and the existing networks. Note: Telex and Transmic are not yet available 
for ISDN subscribers 


PART 2: THE FRENCH ISDN MARKET 


1 Introduction 

France Telecom launched Numeris (the French ISDN) in December 1987 
(RENAN Operation in Brittany); since 1988 the French operator has been 
maintaining a very aggressive marketing policy: 

• Advance commercial launch and nationwide availability by end of 1990. 

• “Attractive” price. 

• Development of partnership between customers, suppliers and installers. 

In spite of all these efforts France Telecom has signed about 400 PRA 
(Primary Rate Access) and 5000 BRA (Basic Rate Access) in 1990 and 
hopes for a total of 7000 BRA by the end of 1991. 

From the beginning, the supply of end user terminals and specific applica¬ 
tions exceeded the demand; however ISDN is now arriving in favorable 
context, and the next few years will see a strong growth of the need for data 
transmission, linked to further development of computing equipment and 
to more and more advanced forms of interconnection. 
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2 The Numeris target 

At the beginning, Numeris involved only the professional users, and particu¬ 
larly all the computing companies which very quickly understood the eco¬ 
nomic sense of such a link. Large companies were also very quickly involved, 
in priority, the banks, the large press groups, the administrative and public 
services, and some specific organisations (like statistical bureaux and refer¬ 
ence libraries with on-line access). 

Medium-range forecasts are that the small and medium size companies will 
constitute the major market in France, in the context of integration of voice, 
data, graphics, and image of the current communication services (Telex, 
telephone, minitel, fax, visiophone, audio-conference, data transfer 
network). 

Logically, the liberal professions and service companies would, a little later, 
be interested in Numeris for a quick and high-volume transfer of documents 
(accountants, telemarketing companies, lawyers, insurance companies, med¬ 
ical organisations, pharmacies). 

As far as individual users are concerned, nobody can predict anything today; 
the price of the equipment will be determinant in this large market; as today, 
most of the products remain for professional use. 

3 France Telecom’s aggressive marketing policy 

As we said in this introduction, France Telecom has concentrated its effort 
on three main axes, since the launch of Numeris in 1987. 

3.1 Advance commercial launch 

According to Franch Telecom, this advance commercial launch will enable 
end-users to be quickly involved in ISDN and its different applications. 
France Telecom plans to reach 150,000 Basic Rate Access (BRA) users by 
1992, and at this date, Numeris should become profitable for France Tele¬ 
com. In 1995, France Telecom plans that between 500 000 and 700 000 lines 
“equivalent to Basic rate access” will be installed in France. 

3.2 Development of partnerships 

In these partnerships, three parties are concerned: 

• The customer who expresses a requirement for improvement to or 
development of a specific application (using ISDN). 

• France Telecom which examines the requirements of the customer and 
provides its experience and its consultancy (sometimes, its money). 

• An information provider (IP), who provides his competence to realize 
or supervise the project. 
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Four main criteria of a partnership may be distinguished: 

• Economic realism: the three partners will support the cost of the devel¬ 
opment. 

• Feasibility: the expert analysis must lead to an economically viable 
project. 

• Subsequent commercialization: the developed application must be com¬ 
mercialised, meaning that it must correspond to a significant market. 

• Innovation: the Numeris potentialities must meet the customer re¬ 
quirements. 

A financial contribution from France Telecom is not automatic. This contri¬ 
bution can partially cover the costs of development, but not those of 
equipment. 

SICOB 90 allowed France Telecom to sign nine new contracts, bringing the 
number of “Numeris partnerships” signed to about 50. Now every main IT 
manufacturer, as well as the eight first French SSII (Information Providers) 
are involved in this process. 

ICL and France Telecom signed their first Partnership Agreement for ISDN 
application development on 21 June 1989. This agreeement shows the special 
commitment of both companies to the growth of ISDN applications. 
“Cooperative working”, using ICL’s ISDN Workstation and Desktop Con¬ 
ferencing (an ICL ISDN product), was selected by France Telecom as the 
first development under the agreement (Fuller, 1991). 

3.3 “Attractive" price 

Two modes of traffic pricing are offered. Telephone traffic is tariffed as the 
normal current telephone service. Data traffic is tariffed as TRANSCOM, 
which is approximately 1*8 times the telephone service (Price in September 
1990). 

It is a very “attractive” tariff for data transmission, largely below the current 
dedicated line tariff. For example, a fax of ten pages costs three times less 
using NUMERIS. Fig. 6, 7 and 8 give an idea of the price positioning of 
Numeris. 

4 Numeris’s offer 

4.1 The slow start 

Although Numeris is currently taking its first steps, many people think that 
it will transform their company organisation, their working methods, their 
communciation strategies. 
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BASIC ACCESS 


initial cost_ 

access price to NUMERIS 665 F * 


basic subscri ption 


supplementary services proposed and invoiced at a fixed price: monthly subscription 


calling party Identification to the called user 

subaddressing for selection of a specific user terminal 

systematic offering of waiting calls 

terminal portability 

300 F* 

supplementary services proposed and invoiced as used 

subscriber private meters i pnclng unit / use 

national call forwarding 1 pricing unit / use 

momessage 0,45 F * 



complementary subscription 


telephone amenity 


total cost 
double call 
terminal forwarding 


* without V.A.T. 

Fig. 6 France Telecom ISDN prices 


Any innovation, with a national or international significance, must necessar¬ 
ily go through a latency phase because peoples’ habits change more slowly 
than technology advances. 

People should be patient, and teach the deciders that they are breaking new 
ground technologically speaking. 

According to France Telecom, the slow start of Numeris is due not to the 
operator (itself) who has adhered to the time-table, but rather to the manu¬ 
facturers who are slow to design specific ISDN equipment. It is important 
to note that the implementation of ISDN specifications is not yet fully 
standardised, and that manufacturers are waiting for them. This means that 
the priority for the different national operators is to agree to require manu¬ 
facturers to work to an international standard. 
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PARIS/PARIS 

2400 Bits/Sec 

ISDN 

Price (FF/mn) 

0,12 

1,9 

Speed (Kb/mn) 

12,8 

468 

File (Kb) 

100 

100 

Time (mn) 

7,80 

0,21 

Cost (FF) 

0,93 

0,40 

File (Kb) 

500 

500 

Time (mn) 

39 

1,06 

Cost (FF) 

4.68 

2.,03 

File (Kb) 

1000 

1000 

Time (mn) 

78,1 

2,13 

Cost (FR 

9,37 

4,05 


Fig. 7 Comparative prices (for file transfer) between an analog telephone line and NUM- 
ERIS, on a distance inferior to 50 kilometers 


PARIS/MARSEILLE 

2400 Bits/Sec 

ISDN 

Price (FF/mn) 

2,57 

4,86 

Speed (Kb/mn) 

12,8 

468 

File (Kb) 

100 

100 

Time (mn) 

7,80 

0,21 

Cost (FR 

20,04 

1,02 

File (Kb) 

500 

500 

Time (mn) 

39 

1,06 

Cost (FF) 

100,23 

5,15 

File (Kb) 

1000 

1000 

Time (mn) 

78,7 

2,13 

Cost (FF) 

202,26 

10,35 


Fig. 8 Comparative prices (for file transfer) between an analog telephone line and NUM- 
ERIS, on a distance superior to 100 kilometers 
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As we said previously, France Telecom is working in two directions to 
activate the process; the Information Providers (named “SSII” in France), 
and the large French companies working closely with these SSII, considered 
as “pilot sites” in charge of opening a “large public usage of ISDN”. 

Today, ISDN equipment and applications are still expensive, but already 
provide a great change in a few companies, especially those which need to 
be in permanent visual and audio contact; it is a bet on the future of which 
every current Numeris user is aware. 

42 The Numeris equipment 

42.1 ISDN telephones France Telecom asked a few French companies to 
develop ISDN telephones (SAT - Matra - Alcatel). 

We could qualify those terminals as “Super telephones” mixing a lot of 
functionalities and a high audio quality. A liquid crystal display is provided 
on the telephone allowing the user to know the caller’s identity before 
picking up the hand-set. 

Some functionalities provided: 

• Call forwarding, 

• Directory, 

• Unanswered calls, 

• Charging information, 

• Sub-addressing, 

• Portability. 

It is also possible to connect the Minitel to the ISDN phone, allowing two 
simultaneous communications: Voice and Minitel. 

4.2.2 ISDN adaptors A set of external adaptors has been developed, 
allowing the connection of existing equipment to Numeris. 

There are 5 types of adaptors: 

• Analogue/So: It enables the restitution of a complete analogue interface 
(feeding, signalling...). Also recreation of a “simple” digital telephone 
terminal for Telefax service needs. 

• X21/So: It enables use of any equipment working with Transcom, 
offering a 64 Kbits/s rate (or 56 Kbits/s for a connection with the 
U.S.A.). It conforms to the CCITT recommendation. 

• V35/So: It enables use of any V35 equipment, with the possibility of 
working in permanent activation (for a Transpac access). 

• X25/So: It enables management of access at any rate up to 64 Kbit/s. 

• V24/So: It enables management of access at any rate up to 19 Kbit/s. 
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Unlike the Sq interface add-on board, the adaptors do not always reach the 
64 Kbit/s rate and furthermore do not allow use of both B channels at the 
same time. They do not change the maximum rate of the terminal and they 
only adapt the communication to the ISDN protocols. 

4.2.3 PC/PS ISDN add-on boards They turn a micro-computer into an 
Open terminal, giving it access to the D and two B channels. 

Through the B channels, they allow: 

• Quick data transfers PC/PC, PC/Host (X25, ECMA 102), 

• Sound or image transfer to any standard, 

• Digital telephony emulations, 

• Local networks bridging (NetBios emulation, TCP/IP gateway). 
Through the D channel: 

• Back-up of signalling and processing by the PC/PS, 

• Under VN3, management of interactive services in packet mode 
(Videotex, Terminal emulation). 

In France, about fifteen boards are on the market (ICL, Matra, OST, 
XCOM,...), every one different, which is an indication of the wide diversity 
of possible applications. 

4.2.4 Telefax A standard has been specially defined by the CCITT gov¬ 
erning the telefax transmission at 64Kbit/s: the Group 4 telefax (G4). 

This standard guarantees some multiple services, and ensures the compatibil¬ 
ity of a range of machines. 

The G4 telefax enables telecopying an A4 page in less than 5 seconds with 
very high print quality. Still very expensive, the G4 telefax currently concerns 
large-scale telecopy users (sending a large number of documents). 

Some manufacturers enable G4 telecopy on PC, using an add-on G4 fax 
board (DCS company). The G4 telecopy will certainly be one of the major 
applications used. 

4.2.5 PABX (Private Automatic Branch Exchange) A new generation of 
PABX is arising in France responding to the Numeris market and exploiting 
every ISDN possibility. This PABX mutation affects the entire PABX 
market. 

Offering an integrated service for both telephony and data processing, 
multiservice PABXs are already an important element of the internal com¬ 
munications in a company. The launch of ISDN and its standardized 
interfaces increases the role of the PABX enabling an extension of its 
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integration possibilities beyond the private area. It implies that the PABX 
of every company is enhanced to access Numeris directly, with either one 
or several basic rate accesses (2B + D), or with a primary rate access 
(30B + D). 

To do this, every PABX must first use time-division switching techniques to 
take advantage of the digital infrastructure potential, and, secondly, imple¬ 
ment the ISDN improved signalling (D protocol) to enhance the Numeris 
facilities and services. In addition, the PABX has to provide a normalized 
To and/or T 2 interface on the public network side and Sq and/or S 2 interfaces 
on the terminal side. 

Progressive evolution from analogue to digital: 

The greatest technical changes concern the small PABX with a capacity less 
than 100 terminals. Most of those installed today are analogue, and the 
evolution towards Numeris implies a development of a new generation of 
products. The transfer of analogue systems towards digital systems has 
already started in middle range equipment (a few hundred terminals) and 
with the aid of new ISDN components, we can expect a quick change for 
small capacity systems. The launch on the market of small Numeris PABX’s 
at a competitive price is announced for 1991. The price of these PABXs will 
be approximately the same as of the analogue ones. 

Generally, the price of ISDN equipment is still very high, but the various 
developments implemented by manufacturers will enable ISDN users to be 
confident of the future. The profit on an ISDN product today is small 
because manufacturers intend to supply a worldwide market, which is not 
yet mature. This will be the major factor to ensure a decline in prices. 

4.3 ISDN applications 

SSI Is (I.P.) and information manufacturers have been developing for more 
than two years a lot of new applications, that may be divided into different 
categories. 

The partnership elaborated by France Telecom is certainly responsible for 
so many applications. One can only regret that today these applications are 
far too specific, and hope that this will change with the increasing demand. 

The majority of existing applications use a PC/PS as terminal and it is 
impossible to consider ISDN technology as a separate technology; if the 
PC/PS workstations had not progressed at the same time, we could not have 
imagined all these ISDN applications. But the PC/PS price is still a brake 
on ISDN development. 

The different categories of ISDN application include the following: 
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4.3.1 Tele-computing or data transmission Data communication is a 
large field of application of ISDN. As a matter of fact, the new network 
provides many advantages: speed and cost, with quality (low error rate, fast 
call setup), security (caller identification, password possibility), reliability 
(connection control). 

Numeris offers a new data transmission network, with telephone pricing 
and flexibility. With its call-duration-charging and its high rate, Numeris is 
oriented more towards the short and large data transfers (images, docu¬ 
mentation, software). 

Examples of tele-computing applications using Numeris: 

• Credit Agricole (French bank): 

Connection between an on-line electronic payment terminal and a bank 
server, software downloading, statistics consultation. 

• Agricultural management centre: 

Automatic transfer of accountancy data files for farms. 

4.3.2 Image applications More than a third of the partnerships signed by 
France Telecom concern image applications. Standard solutions are becom¬ 
ing possible with the advent of compression and decompression boards for 
VGA screens. Some very sophisticated medical image transfer systems exist. 
We can also include in the “Image family” the video-conferencing, telecon¬ 
ference and remote monitoring. 

Examples of image applications using Numeris: 

• FNAIM (major estate agency group): 

Display of photographs of houses for sale, selected from a central 
database. 

• National weather forecast: 

Satellite meteorological images serve for the distribution of images 
during the TV news (TFl, a French TV channel). 

• Kipa (press agency): 

Remote selection of press agency photos to figure in different press 
reviews. 

4.3.3 Multimedia applications These applications mix audio, data, graph¬ 
ics, images and texts. They may be compared to an audio-videographic 
videotex. They are mainly used as public applications, either for remote 
teaching (formation a distance), for general information (use of public access 
terminal), for image catalogues with texts, or EDI. 

Several applications for specific needs are already packaged as standard 
products. 

Example of Multimedia application: 
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• FNAC (major French record retailer) 

Record-listening and photographic displaying (of the record cover), 
weekly downloading of new records. 

Conclusion 

France can today be considered as the leading country in terms of the 
availability of ISDN lines and also the number of applications running on 
ISDN. For this, there is a considerable amount of initial experience mostly 
gained with the techniques associated with the ISDN (NUMERIS) develop¬ 
ment, i.e.: Transpac, Videotex. 

The real take-off of the French ISDN market is happening now. In the 
minds of decision-makers, NUMERIS is slowly becoming the best solution 
for data communication networks (e.g. Multimedia applications); but the 
real dimension of ISDN will be perceived when all the ISDN in different 
countries are connected and operational. The second important step for the 
market will depend on the effort of innovation, in terms of terminals and 
applications, that the manufacturers and information providers will be able 
to give. 
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The Telecomms Scene in Spain 
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ICL, Madrid, Spain 


Abstract 

The growth of the Spanish Telecomms Market. 

Spain has to be ready for the challenge of 1992. Both users and 
suppliers seem to be expecting this year to increase the use and 
development of communications products. However, the ISDN service 
looks like the largest question mark ... 


1 Introduction 

As far as the EEC countries in the 1980s are concerned, the development 
of the telecommunications services market in Spain has been one of the 
largest. This growth is expected to continue at least until 1992, the year in 
which events are going to take place in this country such as the Olympic 
Games in Barcelona and the World Trade Fair in Seville, which will both 
require a large communications effort. 

Value Added Network Services (VANS) are one of the most important fields 
in which demand has increased. The last decade has shown technical consol¬ 
idation of these services and of user knowledge. The 90s will begin with a 
great demand for these services, both from users and private companies. 
The actual state of the Videotex or X.400 Electronic Mail markets prove 
that things are moving fast in this direction. 

Things are moving in the ISDN direction as well, but we will probably have 
to wait a few more years to substitute the actual network with what has 
been called “the universal socket”. 

When discussing the past, present or future of communications in this 
country one is immediately led to Spain’s telecommunications provider, the 
powerful PTT, Telefonica, which has embarked on a major expansion 
programme in order to meet the demand for new telephone lines and 
additional services. In fact, the plans for 1990 were to expand the public 
network by investing £3,200 million and adding one more supplier AT&T, 
to its base of Alcatel and Ericsson. 
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2 Networks and Services 


2.1 Bit of history 

The National Telephone Company of Spain (called Telefonica since 1984) 
used to be owned by ITT before it was nationalised in 1946. It has the 
responsibility for telecommunications services, except telegraphy, telex and 
message switching, which are provided by the Ministry of Transport, Tour¬ 
ism and Communications. 


Telefonica currently enjoys a monopoly over all network services, including 
the value added ones, as well as telephone handsets. The connection of any 
equipment to the national network is not allowed without the approval of 
the PTT. 

2.2 Status of the current network 

By 1990 only 15% of local lines were digital, with the aim of achieving 40% 
digitisation by 1992 (73% of trunk lines). By the end of 1993, the forecast 
for local exchanges is to have 8,100, ie half of them, digital. 


In terms of fibre optic cable, Telefonica has planned the installation of 
3,628 km for 1990 and 900 km for 1991 capturing 85% of the Spanish 
market, with a forecast for 1992 of 11,600 km in all. 

2.3 Network Services support. Data communications. 

A) IBERPAC. 

IBERPAC was the first packet switching system installed in Europe, operat¬ 
ing since 1982 and supporting X.25 technology. In the beginning the service 
was used mostly by banks and financial organisations. Nowadays, it supports 
international data transfer (conforming to international standards allowing 
it to be connected to the packet switching networks of other countries), 
Teletex and Videotex. Basically it provides data traffic services between 
terminals and computers of different types and operational modes, and acts 
as support for additional data communications services. 


It offers two basic communications services, permanent virtual circuits 
(PVC) and switched virtual circuits (SVC), with some optional user facilities 
like closed user groups with outgoing or incoming access, reverse charging, 
fast selection, PAD, multilink access, network user identifier, multichannel 
access, etc. 

Iberpac is organised in two areas, the area of the carrier network on which 
the operation is in packet mode and the access area where different types 
of terminals co-exist, connected with different operational modes. 


494 


ICL Technical Journal May 1991 


For various reasons Iberpac charges are the highest in Europe, one of the 
most important being the fact that they are using their own packet switching 
technology, TESYS System, designed and developed by Telefonica Sistemas 
with considerable cost in R&D. This system accommodates the connection 
of data terminals with different protocols as well as packet terminals con¬ 
forming to CCITT standard. 

Another of Iberpac’s problems is the slow transmission rates available, up 
to 9,600 bit/sec in theory, but not always ready to work at that speed. 


SERVICE SPEED 


FEATURES 


IBERPAC (X.25) 2400 bits/sec 

4800 bits/sec 
9600 bits/sec 


Duplex and 
Synchronous. 
Modem included. 


The Iberpac main nodes are located in Madrid, Barcelona, Seville, Leon, 
Valencia and Bilbao and there are 71 local access points to other cities and 
industrial areas. 


IBERPAC CONNECTIONS 

1990 1991 1992 

104,640 139,520 152,000 

Source: Telefonica Sistemas. 


B) IBERCOM. 

IBERCOM is defined by the PTT as an advanced integrated telephone and 
data transmission service, and is being developed to provide ISDN eventually 
to businesses at 64 Kbs, integrating the basic services of Iberpac and RTC 
(PSTN). 

Ibercom is a multi-user service digital network, interfacing with both the 
public switched telephone network and the public switched data network. 
Furthermore, we can consider it as a global telecommunications concept 
developed in three different areas: 

• Offering typically private network facilities, specific for each company. 

• Providing real cooperation between the technical departments of every 
company and the PTT, in order to find the most cost effective telecomms 
solutions, speed them up and update them if necessary. 

• Access, from the start, to integrate voice and data, knowing that the 
solutions achieved will be accepted by the future ISDN. 

As everybody recognises, the “bridge” to the future ISDN service is not as 
important to Ibercom success as the real commitment to the customers’ 
business needs. The possibility of designing their own solution together with 
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the high speed of digital transmission seems to be reason enough to justify 
its acceptance. 

The Ibercom network has 425 terminal centres MD 110, 35 frontal centres 
AXE and 3 frontal centres 1240. The installed base of lines was 170,000 in 
August 1990, of which 80,000 were installed in 1989. The network is used 
in more than 250 different companies (mainly large organisations) both in 
the private and public sector. Telefonica’s forecast is for 250,000 lines by 
Q1 1991. 

C) Text Communications Services. 

C.l) Telex. 

The Spanish Post Office (CORREOS) is the body responsible for telex 
services, leasing the necessary lines from Telefonica. The Spanish telex 
network comprises eight transit exchanges, 60 regional exchanges around 
the country and two international gateway exchanges one in Barcelona and 
the other in Madrid. The telex network can interface with Iberpac. 

C.2) Telefax. 

The installed base of facsimile machines is estimated to be 128,700 machines. 
The terminal equipment has to be approved by Telefonica, but supply to 
the market is directly through private suppliers. 

C.3) Teletex. 

This public service uses the Iberpac network and a converter to obtain 
connection to the telex network. The service provides alphanumeric trans¬ 
mission and its features include access to international networks through 
the X.75 interface. The forecast for the end of 1990 was for 13,600 users. 

C.4) Ibertex. (See Videotex in VANS) 

3 Value Added Network Services (VANS) 

The Value Added Services offer many more facilities than the ordinary basic 
services, using them, but increasing their resources and making the user 
interface much simpler and more friendly. 

The current movement in Spain towards these services makes us believe that 
the technical users consolidation of the eighties will be followed by a strong 
demand in the nineties. 

I would like to review briefly the most popular VANS in Spain. 

3.1 Mobile telephony 

Spain was one of the first countries in Europe to offer the NMT 450 service, 
back in 1982. The estimated subscriber base is 50,000 at the end of 1990. 
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Telefonica has recently awarded a number of contracts for mobile cellular 
networks. Two companies, Intesa and Telcel are each to supply the basis of 
a cellular network, looking forward to 1992 with the World Trade Fair in 
Seville and the Olympic Games in Barcelona. 

Nowadays, the service covers most of the country, which is the main reason 
for the increase in demand. Two other reasons are; the lower cost of the 
mobile telephony equipment (TMA) and the greater understanding of this 
service by the users. The forecasts are for growth up to 15% of the global 
telecommunications bill by the end of the decade. 

3.2 Ibertex, the Videotex Service 

Usually known as Videotex, the telematic service which relates and intercon¬ 
nects the Spanish PSTN (RTC) with the X.25 public service (Iberpac) for 
data transmission, has experienced one of the biggest growths in the tele¬ 
comms world. We find many reasons for this but we always see the first one 
as the PTT’s commitment to the service. 

The interconnection between the PSTN and Iberpac is called the Ibertex 
service, available anywhere in the country at the same cost. The VTX user 
will find different levels in the Ibertex Service, depending on the type of 
information to be accessed. 


IBERTEX SERVICE LEVELS 


Level 

Telephone access 

Characteristics 

Bl 

031 

Charge Type 1 

B2 

032 

Charge Type 2 

B3 

033 

Charge Type 3 

BO 

030 

Services Guide 

B4 

034 

Free Information 

B5 

035 

Reverse Charge 

B6 

036 

Internat. VTX link 


The Services Suppliers are based on a UNIX hardware platform and a set 
of software modules. 

Within the VTX software we find the Kernel (managing X.25 and ASCII 
comms, statistics, languages external processes, ...) and a set of standard 
applications generally including order entry, professional electronic mail 
with X.400 interface, multicriteria method of searching for data, ... etc. 

Due to the many different DBs to be accessed, it is impossible for software 
companies to develop interfaces for every single DB as a standard solution. 
A result of this is the market’s demand for useful tools to be included in 
the software packages, which will allow users to develop their own applica- 
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tions corresponding on their own specific requirements (type of DB, hard¬ 
ware which contains the DB, number of records, frequency of modification, 
method of accessing the DB, ... etc). 

The growth amongst market agents (Service Providers, VTX terminals, 
general public telematic knowledge) together with the PTT’s commitment 
leads to the conclusion that Spain will be the second European telematic 
country by 1992, with a forecast of more than 400,000 terminals. 


VIDEOTEX GROWTH FIGURES 

1990 

1989 

1988 

Number of connections 
(Average per month) 

- 

120,000 

30,000 

Number of DB 

175 

120 

35 

Services Suppliers 

70 

45 

20 

Terminals 

200,000 

45,000 

5,000 

Average connect time 

- 

12 min 

- 

Connect time 

42,922 hours 
(Feb) 

7,900 hours 

— 


Source: APV and Telefonica 

3.3 Electronic Mail, X.400 and X.500 standards 

With the X.400 and X.500 standards, the CCITT is looking for the intercon¬ 
nection of the electronic mail services all around the telecomms world. In 
Spain the most similar thing to an X.400 electronic message system is called 
Mensatex, first introduced by Telefonica in 1988, which allows end-to-end 
data communication through the Iberpac network or the PSTN. The mar¬ 
ket’s interest is enough to convince the Post Office to start implementing 
their own service by the end of the 1990. This will solve the problem of 
many private electronic mail networks working separately and without the 
possibility of interconnecting to each other. It looks as if X.400 standards 
will be the basis for the first global messaging system. To achieve this it is 
necessary to complement the rules with the X.500 ones, and for these rules 
to be completed, solving the message security problems, the access control 
and agreeing the global directory. 

34 EDI 

Linking the various parties in the EDI chain are invariably the value added 
networks (VANS) or value added data services (VADS). In Spain we will 
find the same problems as in the other European countries. First of all 
standardisation; the communication rules must be the same for all the 
computers involved in the electronic data interchange. The internationally 
recommended standard is EDIFACT, generally accepted by the vast major¬ 
ity of the European countries. 
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Another important aspect relates to the software packages and the physical 
transmission support. There are some products solving the elecronic inter¬ 
change problem, and the network used in Iberpac, which is not enough but 
is helped by three compensation centres owned by General Electric, IBM 
and Telefonica, working as mailboxes, storing the information. 

An important effort is being made by AECOM, the association which 
controls the product bar codes. The first step is to agree to a common 
language between buyers and suppliers as far as bills and orders are con¬ 
cerned. Once they achieve this, Electronic Data Interchange between sup¬ 
pliers and supermarkets will become a reality. 

A further effort was made in 1984 with the implementation of the Odette 
project using EDI in the Spanish automobile industry. The problem is that 
being born before EDIFACT, it works to another standard, although there 
are plans to change it in the near future. 

4 The Future: ISDN 

ISDN is known in Spain as RDSI; Telefonica decided to implement Ibercom 
in 1985 as a first step, due to the lack of international agreements. The MD 
110, AXE and 1240* digital switches will have to be able to change towards 
ISDN (plus the 5ESS switches) once Telefonica has announced the ISDN 
commercial capability by the end of 1991 and the country-wide service by 
the end of 1992; these seem to be extremely optimistic predictions. 

The first stage towards the full implementation of ISDN in Spain was in 
1985 with a pilot service using AXE and 1240 systems. This was useful as 
a first experiment but without real value, due to its lack of compatibility 
with the CCITT recommendations. 

The second stage included real users, with two pilot AXE digital switches 
supplied by Intelsa in 1989. The project suffered a big delay and by Sep¬ 
tember 1990 it was still not working. 

The third stage was planned by 1991 and included the commercialisation of 
the service, but the delays make us think that the Spanish ISDN network 
is still a long way from full implementation. However, it will be interesting 
to see how quickly Telefonica attempts to manage this transition while 
Ibercom continues to have commercial success. 


*AXE: Ericsson product 
1240: Alcatel product 
5ESS: AT&T product 
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5 Objective: 1992 


The telecommunications field is not left out of account in a country which 
is looking forward to the year 1992 in most financial, commercial and 
political areas. For in that year, not only will Spain host the Olympic Games 
in Barcelona, but also the 1992 World Trade Fair in Seville. 

There will be significant increases in the demand for digital main lines, fibre 
optic cable installations, Iberpac and Ibertex connections and finally ISDN 
service lines, most of them preparing the country as the world becomes 
connected to Spain through telecommunications. 
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Future Applications of ISDN to 
Information Technology 

Alan R Fuller 

ICL (UK) Ltd., Windsor 


Abstract 

The paper first examines the special advantages of ISDN for com¬ 
puter users. It indicates the scope of ISDN for innovative applications, 
especially those which it would be too difficult or too expensive (if 
not impossible) to achieve by any other means. 

It then describes by way of example, a system for “DeskTop Confer¬ 
encing” developed by ICL. This is a multimedia system enabling two 
or more persons, using both speech and vision and at remote 
locations, to cooperate on drafting text or on some engineering 
design. 

The paper ends by sketching some of the possibilities opened up by 
ISDN for future applications. 


1 Introduction 

The fundamental technical principles underlying the architecture of ISDN 
and its use for information transmission are discussed elsewhere in this issue 
of the journal (cf. Orange, Calot & Spiracopoulos, and Larraz). Sufficient 
description of parts of ISDN is included here for clarity and ease of reading. 

Most observers of the telecommunications industry over the past decade 
have viewed ISDN with some scepticism. We should not be too surprised 
that, even today, the uses and the perspective of the potential value of ISDN 
tend to be limited. 

Noting that the acronym “ISDN” stands for Integrated Services Digital 
Network, if we take common dictionary definitions for these words, we 
might expect a linking of the following ideas: 

Integrated: combination of parts into a whole 

Services: provision of what is necessary, possibly in return for some 

payment 
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Digital: representation in discrete form by digits 

Network: arranged in the form of a lattice structure 

Since ISDN has such a wide-ranging definition, it is not surprising that it 
means all things to all men. More notably, it is easy to see how different 
people see ISDN as something different. For example, a telecommunications 
manager whose life revolves about reducing the cost of telecommunications 
service to users will tend to emphasise the network and physical level integra¬ 
tion aspects of ISDN. On the other hand, a telecommunications engineer 
might consider ISDN to be, in the main, a digital transmission system. 

Again, an operator of a network (e.g. a PTT) might consider the features 
of the services provided within ISDN to be more important than any other 
issue; in other words the scope for flexibility in the provision of services 
may well be uppermost in his mind even though it may not yet be known 
just what services will be provided over an ISDN. 

ISDN is examined in this paper chiefly as the USER will see it and its 
applications; by contrast ISDN is briefly analysed as a means for the transfer 
of information. 

2 Transfer of information by ISDN 

Ever since the beginnings of the telecommunications industry (with tele¬ 
graphy in the late 1870’s), telecommunications engineers have applied a 
fertile imagination to innovation. To send information over long distances 
has been one of many goals. While this was usually quite costly international 
telegraphy demanded long distance cables. When they could not be laid 
overland, undersea cables were installed. Later of course radio links were 
added. Whenever a new frontier was reached, new technologies were ex¬ 
ploited. The new technologies were always expensive to deploy initially, 
which was perhaps the most important factor the telecommunications engin¬ 
eer had to contend with. 

Consequently, the telecommunications industry has become renowned for 
the number of different techniques it employs to reduce costs. Although 
other factors matter too, cost has been the dominant factor giving rise to 
diversity in telecommunication. There are today a plethora of encoding/ 
decoding techniques, many different techniques of modulation and types of 
physical transmission media and a variety of methods of multiplexing. 

In the field of data communications a further diversity exists: there are many 
different communication protocols suitable for different forms of network 
topography. All data communications and telecommunications methods are 
constrained by the technology employed while the various techniques can 
be characterised in turn by a set of attributes which are important since 
they can determine the most economic solution to a business problem. 
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Any business problem makes a number of demands on data communication 
and on the telecommunications infrastructure. The technology available to 
solve these particular business problems is well established but it is instruc¬ 
tive to understand some aspects of why the technology was selected. For 
ISDN, considered as a simple telecommunications technology, the same 
principles apply as a couple of simple illustrations will show. 

For example, authorisation of credit cards typically requires the exchange of 
alphanumeric data between a card reader and a remote computer holding 
a credit card information base. In this case immediacy is important, in other 
words the whole transaction has to be completed in a short time while the 
customer waits. Transmission speed is not a major factor because the amount 
of information transferred is relatively small; but the cost of credit card 
verification is always important. 

Similarly, to transfer, for instance, a street plan by facsimile requires trans¬ 
formation of the input image into a series of codes which on reception can 
faithfully reproduce the original with appropriate definition and grey scale. 
Here immediacy is not so important but speed of transfer can often deter¬ 
mine how many pages of information are sent. Hardcopy from the output 
device is obviously essential while the cost involved in transmission is, as 
always, an important consideration. 

Thus the various attributes of available technologies must be matched with 
the demands of the problem, and, after suitable compromise, appropriate 
data communications and telecommunications technologies selected to solve 
it. If ISDN is regarded as no more than another telecommunications techno¬ 
logy with particular attributes and cost parameters, it will meet the require¬ 
ments of many present-day business problems. 

3 Benefits of ISDN for Information Transfer to the Business User ^ 

Because of the tremendous business benefits to be obtained, the most exciting 
prospects offered by ISDN to the user are where new applications become 
possible - and where old applications can be completely re-implemented. 
Its special advantages arise from its many facets, described in more detail 
elsewhere in this issue in the papers referred to in §1. Amongst these special 
advantages are the following: 

3.1 Because the information transferred by ISDN is in digital form, it may 
represent speech, data, text and images (including slowly changing images). 
ISDN is not restricted, as are networks using analogue methods, to speech 
with the limited capability of sending data imposed by a modem. 

3.2 Because ISDN was designed to employ digital transmission of high 
quality speech the user is provided with digital transmission of data and 
images at far higher speed and at much lower cost. In due course this high 
speed transmission will be available as widely as the present PSTN. 
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3.3 Because digital techniques are used, information is transferred consid¬ 
erably more accurately and more reliably. 

3.4 ISDN is actually built on a digital infrastructure that is already in use 
by the PSTN-in the exchanges and inter-exchange links - so that, when it 
becomes universal, there can be economies of scale with every prospect of 
very economical transfer of information. 

3.5 Access to an ISDN is via a well defined interface, in fact a telephone 
line as now used. However, over this one telephone line a user can employ 
two independent channels for information as compared with only one on 
existing lines. 

3.6 A third channel is also provided, primarily for signalling, but it can 
also be used to transfer a limited amount of information; in fact it can send 
data at speeds comparable with the current Public Switched Telephone 
Network. 

3.7 ISDN employs messaging techniques for establishing voice and data 
calls, ie for signalling. As a result of the rapid data transfer, call set up times 
are at least an order of magnitude faster than with current PSTN. The 
messages are no longer simply of the form “connect me to subscriber X”, 
but offer a much more comprehensive scope. The progress of a call across 
the network is signalled in detail and the reason for failing to make a 
connection is indicated with greater clarity. In simple terms, the ISDN can 
say not only when a call fails to connect but, more importantly, why it fails 
to connect. 

3.8 The signalling messages can indicate who is making the call - Calling 
Line Identification. Presentation of this information to a user receiving a 
call can provide an important measure of security - one not readily achieved 
using the current PSTN. 

Comparing costs per “data packet” using different techniques, even the cost 
of sending a letter by ISDN rather than traditional post is very attractive. 
It can be sent person-to-person with an immediacy simply not achievable 
by the regular post. 

Indeed ISDN offers vast improvements over many other technologies. Its 
attributes taken together open up the possibility - using switched ISDN for 
transferring information - of applications that would otherwise simply be 
quite uneconomic. 

4 The impact of ISDN on current telecommunications generally 

One or two examples may illustrate the impact of ISDN on current applica¬ 
tions of telecommunications. 
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For voice communications, the apparent impact is fairly small. In most 
western industrialised countries, the present telephone network provides 
adequate service, but in many second world countries the networks are very 
old and in dire need of modernisation. ISDN will be seen to provide a 
telephone service comparable with what we have today in say the UK and 
USA. 

However, the ultimate impact of ISDN on voice communications is much 
wider than this. In the USA, the telephone is used for a far wider range of 
purposes than in most other countries, one of which is to access data- 
oriented services via the telephone. 

Again, in private companies, PABX systems have for many years offered a 
wide range of facilities simply in order to make the telephone easier to use 
as well as to make better use of a caller’s time. For example, call divert to 
another number, call barring and, call back when free are features present 
on all modern PABX systems. 

ISDN offers the scope for most of these facilities to be available also on the 
public network offering all their advantages to the private user that were 
previously available only to the business user on his PABX. 

Using ISDN, simple transfers of text will be much faster than with PSTN. 
Bulk transfer of filed data is a well-known technique practised for many 
years but subject to significant constraints when using the PSTN, namely a 
low effective throughput of data and the unreliability of the transfer. Both 
of these are vastly improved with ISDN. Through the PSTN, a data rate 
of 9600 bits per second (bps) is theoretically possible. However, the reliability 
of a connection at this speed is often poor and reliable data transfer at rates 
above 2400 bps may not be possible. ISDN immediately offers a higher 
reliability at a data rate of 64000 bps. Typical bit transmission errors are 
of the order of less than 1 in a million. 

Thus large files can be transferred much more reliably using ISDN than 
with PSTN, and, since both ISDN and PSTN tariffs are based on usage, 
i.e. proportional to connect time, the higher transfer rates of ISDN mean 
much shorter calls and hence much lower charges. 

The high data rates will mean not only that text and binary information 
can be transferred, but that files containing images can also be transferred 
cost-effectively. The recent enormous growth in use of facsimile bears out 
the truth of the saying “a picture is worth a thousand words” but this 
growth is predicted to grow even further when Group 4 facsimile is intro¬ 
duced. Group 4 is specifically designed to exploit ISDN. The impact of 
Group 4 facsimile on the end user may be simply appreciated: it takes 30 
seconds to send the information on an A4 sheet using the Group 3 standard, 
but only 3 seconds using Group 4 facsimile over ISDN. 
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5 ISDN and new application areas 

So far in this paper the specific advantages of ISDN have been mentioned. 
The preceding examples could be regarded as applications of ISDN which 
use the features of ISDN but via existing forms of service. 

There are however examples of applications which are genuinely novel; 
ICL’s DeskTop Conferencing is one such application. 

5.1 Cooperative Working 

In a telephone conversation between colleagues each has a set of mental 
facts and images. For the conversation to succeed many of these must be 
shared; in other words it has to rely on well known language and vocabulary. 
If, say, the conversation concerns the inter-relations between numeric items - 
in a spread-sheet say - the discussion can become quite abstract. The 
exchanges could be much more productive if the participants could both see 
the information being discussed: paper is the most common and obvious 
medium. One method is to refer to documents (which could include dia¬ 
grams) interchanged previously. 

For a more immediate response, one may resort to “mark up a copy and 
fax it to me”. Where the matter discussed is complex, as for example a set 
of engineering drawings, cooperation may be very limited unless the parties 
can both see the same proposed changes to the drawings. Such a result could 
be achieved if both could see the same modifications to a drawing on the 
screens of their workstations. 

5.2 The ICL ISDN DeskTop Conferencing (TM) Application 

The technique of providing simultaneous voice, data and image capability 
at multifunction workstations is not new but sharing multimedia information 
amongst users of workstations is, and so too is its exploitation in the business 
community. What facilities are needed to make such an application a 
success? 

Pairs of multifunction workstations connected by ISDN allow colleagues to 
discuss information presented on their workstations and because they have 
the same image (screen sharing) they have a common perception of the 
information being discussed. But they need much more than this to be 
effective. Although the use of speech is implicit, they also need to be able 
to identify particular objects on the screen to avoid ambiguity. A mouse or 
light pen is an ideal device enabling colleagues to point to or highlight 
information. Both a light pen and a mouse may be used with ICL DeskTop 
Conferencing. 

Working in a cooperative manner, colleagues can rapidly develop proposals 
and agree changes that may be necessary; typically there is a requirement 
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to transfer information between the PCs in bulk fashion. ICL’s DeskTop 
Conferencing Application incorporates a file transfer process which can be 
used either in isolation (i.e. screen sharing stops temporarily) or in parallel 
with other activities (i.e. screen sharing will continue but take priority over 
the file transfer which appears as a background task). 

5.3 Multi-person Conferences 

Simple two-party conversations are probably the commonest, but, increas¬ 
ingly, multiparty conferences are held by groups of colleagues who are 
geographically separated. Ordinary telephone conferences have been found 
to be most productive when conducted in a disciplined manner. One of the 
conference participants typically acts as the chairman and an agreed agenda 
is found desirable to achieve a common approach. 

A similar discipline is necessary, it is argued, when several multifunction 
workstations are connected through ISDN to form such a multiparty confer¬ 
ence. Therefore ICL has incorporated such multiparty features in its 
DeskTop Conference Application. 

Typically one participant acts as the chairman and exercises overall control. 
The information on his workstation screen is seen by all the others who 
may point to and highlight an item of the shared information on their 
screens. Only the chairman may decide what information is seen by the 
conference. He obviously needs the power to allow other participants to 
take over control (just as in a normal voice conference) and features are 
provided to allow this delegation of control. The specific computer applica¬ 
tion whose output is being shared can of course be nominated and changed 
during a conference. 

The individual contributions of those taking part in a multi-party conference 
will clearly need to be identified in various ways. Information on screen 
pointed at by any participant is identified by a different coloured pointer; a 
contribution drawn with a light pen leaves a trace in a different colour 
corresponding to each participant. 

5.4 The ICL Technical Approach to DeskTop Conferencing 

In ICL’s DeskTop Conferencing, a pair of personal computers, each 
equipped with an ICL ISDN interface card, are connected via an ISDN, as 
shown in Figure 1. 

Users can set up data conferences in the same simple way as making a 
telephone call. The computers are now linked by the DTC application 
running as a background process in each of the two personal computers. 
The DTC applications are linked using an ISDN B-channel for information 
transfer. (When the call set-up has been completed, the DTC applications 
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Fig. 1 Facilities needed for Multi-Media working via ISDN. 


use the 64000 bps data transfer path effectively as a point-to-point data link 
and ignore the fact that the data link has been set up via a switched network). 

The DTC applications provide what may seem a simple capability: whatever 
is written to the screen of one PC is “read” by one DTC application and 
transferred using ISDN to its peer application and written on the screen of 
the other PC. In this way screen sharing is effected. The DeskTop Conference 
Application uses standard Presentation Manager to read from and write to 
the screen and handle the keyboard. 

HDLC protocol is used to achieve integrity of data transfer over the physical 
link between the computers. ISDNs in most countries are in their infancy 
as a commercial service and generally not integrated with other forms of 
data networking; but this is not the case in the USA and some Scandinavian 
countries, where there is a greater degree of integration with other networks. 
Further, the reliability of the ISDN as a sub-network is high. For these 
reasons, network and transport layer protocols have not been incorporated 
although it would be fairly simple to do so. 

There is no accepted standard for the application layer protocol for sharing 
screens and therefore ICL has employed the encoding techniques which do 
exist for Group 4 facsimile. 

Once the DTC applications have established the conference link then its use 
is automatic and does not involve the user in any further process. The users 
of course can talk to one another about the information they both see on 
the screen. 

The information which is the subject of the conference is of course independ¬ 
ent of the DTC application which sets up the conference. That information 
may come from industry-standard applications, for instance, spreadsheets, 
word processing packages, packages for computer aided design, even pack¬ 
ages which communicate with other computers and databases. 
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5.5 The ICL Product Package 

Since there are in effect two simultaneous conversations, one between the 
two human beings and the other between the PCs, which must be coordin¬ 
ated, the functions of the telephone must be closely integrated with those 
carried out by the DTC software. A fully Integrated Telephone is interfaced, 
both to the ISDN through an ISDN card inserted into each PC and to the 
PCs themselves. A wide range of telephony functions are provided through 
a single key stroke such as call hold, call back, call divert and transfer call. 
Although the telephone is integrated with the computer to provide many of 
the functions, it behaves in much the same way as a normal telephone. 
However its features allow more cost effective use of the user’s time. 

The ISDN PC card plugs into the PC-AT bus and is therefore supported 
by all ICL Personal Computers based on the Intel 80286, 80386, 80486 
microprocessor family. Because it conforms to the industry standard PC- 
AT interface, the card may also be used with a wide range of industry 
standard PCs which are fully IBM-compatible. The card is driven by the 
PC using a set of device drivers. 

The package marketed by ICL includes the ISDN PC card, the integrated 
telephone, the DeskTop Conference Application, and the Telephony 
Application. It can upgrade a standard PC to a full function ISDN work¬ 
station and has been marketed in the USA for over 12 months. It will be 
marketed in other selected countries within the next 12 months. 

Because the DeskTop Conferencing Applications run in the background of 
the computer while the user uses his own application, a multitasking operat¬ 
ing system is required to support the processes involved. ICL currently 
employs the OS/2 operating system since it best fits these multitasking 
requirements. 

6 New integrated application areas 

In previous sections several examples of different types of integration of 
facilities in one application have been mentioned. Such integrated applica¬ 
tions could be categorised in terms of the type of integration involved. 

For example: 

a) Integration of functions at the physical transmission level. This is 
probably the most obvious feature of ISDN since it is its fundamental 
concept. 

b) Integration of applications which have previously been considered as 
discrete functions (possibly employing different media) but now integ¬ 
rated in their use of common features and services. A typical example 
is the integration of Fax with a directory used for generation of 
distribution lists - as described in outline in a previous section. 
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c) Integration of applications previously considered as being similar func¬ 
tionally but employing different media. A typical example is voice- 
annotation of text and a related electronic mail service. 

d) Integration of applications which are integrated both at the media level 
and with other application areas. One example is a voice-annotated 
document system which can generate addresses for a distribution list. 
Another example is ICL’s DeskTop Conferencing Application. 

These last two application areas are of particular interest since they offer 
the scope for the most valuable ISDN applications which can make very 
significant increases in productivity in the immediate future. 

7 Applications of ISDN involving Multimedia 

A few voice-annotated text systems have been implemented but few have 
had access to advanced communications facilities. Thus, because of the low 
transmission rates, transfer of voice-annotated text documents has been very 
time consuming - if not totally impracticable. ISDN makes such systems 
viable with reasonable transmission times for such multimedia documents. 

There are no well known, commercially available multimedia applications 
which have been integrated with other network-based applications. It is 
interesting to suggest why such multimedia applications have not so far 
been developed. One reason may be that a switched network is frequently 
required but the bandwidth of such a network is too limited. 

ISDN bandwidths make such applications possible. Further, it is probable 
that until the advent of powerful desktop computers the human to computer 
interface for multimedia applications has also been limited. 

Today’s powerful microprocessors can represent multimedia images (e.g. 
text integrated with images) typical in desktop publishing applications. 
Further, with the use of WIMP techniques, the human interpretation of 
voice annotations is readily comprehensible and multi-media applications 
are therefore ready to take off. 

Other facets of the human-to-computer interface ripe for exploitation (be¬ 
cause the microprocessor power can now support it) include “context de¬ 
pendent actions”. Consider for instance editing a letter which includes a 
telephone number and a reference to another document to be sent as an 
attachment. If the user highlights the telephone number with a mouse, one 
could expect an integrated workstation of the future to take contextually 
defined actions. A window with a menu could appear offering the user the 
option to dial the number on the integrated telephone. Alternatively, high¬ 
lighting that part of the text which refers to the attachment could present 
a window with options to use the text as a filename for a whole series of 
database actions. ISDN has a special role to play if the data referred to is 
both voluminous and stored elsewhere. 
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8 Conclusions 


To users the benefits of adopting ISDN for data are significantly greater 
than they are for speech, if only because we cannot talk faster but can 
readily accelerate the transmission of data to take advantage of the greater 
bandwidth of ISDN. Recognition of the benefits of ISDN for sending 
multimedia documents will further encourage its introduction throughout 
the world. Its rate of growth however will be constrained by the large capital 
investment needed. 

ISDN technology allows facilities to be provided complementing those 
offered by related technologies. Taking its specific facilities individually it 
may be that no one of them has such profound impact on applications that 
ISDN is the only economic solution to the business problem. 

However, taken in combination, its facilities can stimulate new and innovat¬ 
ive applications, limited only by the imagination of the developer. In the 
examples quoted in the later paragraphs, it is suggested that the multimedia 
application areas are potentially the most rewarding. The success of such 
applications will, as always, be determined by their take up in the market 
place but the main factor determining success will no longer be cost alone; 
it will be primarily the perceived value of the application to the end user 
and of the business benefits derived. Already, users of the ICL DeskTop 
Conferencing Application are beginning to reap the rewards of an integrated 
approach. 
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A Geographical Information System for 
Managing the Assets of a Water 
Company 

C.E.H. Corbin 

IT. Southern, Brighton, Sussex 


Abstract 

The paper describes how information technology is helping to ad¬ 
dress the business problems that arise from the management of a 
Water pic’s fixed assets which have a current value of £2,469 million 
at 1989 prices and a rolling capital investment program in excess of 
£160 million per annum. The assets are distributed below and above 
ground across a geographical area covering 10,500 square kilo¬ 
metres with a resident population of 4 million. 


The chosen IT solution is to exploit a geographical information 
system (GIS). The GIS has been evolving since 1988 and is due to 
be completed in 1995 approximately. The GIS exploits SUN worksta¬ 
tions, high bandwidth data transmission networks, ICL mainframes 
and a range of application packages. When complete the databases 
associated with the GIS system will be in excess of 150 GBs and will 
be attached to the mainframe and distributed SUN Microsystem 
servers. 


1 Introduction 

The assets within utility organisations such as Southern Water continue to 
absorb vast quantities of resources and as such the pressure to improve the 
management of the assets to optimise the call upon those resources continues 
to grow in order to ensure that the best use is made of the finite resources 
available. 


Southern Water covers a geographic area of 10,500 square kilometres located 
in the southeastern corner of England. The Southern Water area of respons¬ 
ibility covers the counties of Hampshire, Isle of Wight, Sussex and Kent. 
Within this area the water distribution system covers an area of 4,450 square 
kilometres, the black areas shown in Fig. 1. The sewerage system covers 
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Water Region ■ 4,450 Sq Kms 
Sewerage Region ^ 10,450 Sq Kms 

Fig. 1 Southern Water pic - Areas covered 


10,450 square kilometres that is the combined grey and black areas shown 
in Fig. 1. Within this area there is a permanent resident population of 4 
million people with seasonal variations of up to 4.6 million people. 

The number of premises receiving water within this region is 946,000 which 
on average receive 700 million litres of water each day via 11,500 kilometres 
of pipe work from 125 water sources. Some 73% of the water put into the 
supply is abstracted from underground sources or aquifers. Water is pumped 
into the system using electrical pumps after treatment and disinfection. Up 
to 30% of water put into the supply is unaccounted for and over the past 
decade the demand for water has increased by 15% [Schroder 1989]. The 
variations in the weather pattern, which are a current topic of discussion, 
are also placing extra demands on the resources and the assets. 

The number of premises connected to the drainage system within the region 
is 1.696 million. The waste water is mainly drained by gravity through 
24,600 kilometres of pipe work to 393 treatment works which treat a daily 
average of 965 million litres of effluent [Schroder 1989]. 

The “Current Value” of the assets is 2.5 billion pounds at December 1989 
prices upon which a rolling capital program of 160 million pounds per 
annum will continue to be spent over the next ten years. The environmental 
pressures continue to grow which together with the growth in demand and 
renewal program put great pressure on the limited financial resources 
available. 

The underground assets have been placed in the ground over many years 
and as such the knowledge and records about these assets have passed 
through many people and organisations with the result that the currency 
and accuracy of the data about these underground assets is low. The Water 
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Industry is heavily regulated and monitored which in itself demands accurate 
data. This is no bad thing as the health of the nation is heavily dependent 
the quality of the product delivered and the safe removal of the waste 
products. 


2 Business Problem 

The business problem to be resolved is to improve the management of the 
assets and services provided via these assets. Large quantities of information 
about the assets are held on paper, microfiche and in employees’ heads and 
private note books with minimal information held on computers. Access to 
information is required by a large proportion of the employees, which was 
achieved by duplication of the paper records. The records held by office 
staff were often different from those held by field staff as were the records 
held by different field staff servicing the same geographical area. 


In order to improve the management of the asset the first task is to improve 
and make readily available the information about those assets, both the 
static and dynamic data. 


The assets, premises served, customers, etc; are all geographically located 
or dispersed and as such the records are mainly geographically referenced. 
The information is predominantly held on paper maps, plans and forms 
dispersed throughout the organisation. Over the past decade a considerable 
amount of data has been collected by surveying the assets from above 
ground and from entry points such as the 450,000 manholes on the sewers 
and via ‘moles’ that travel through the pipework enabling video recordings 
to be made on the internal state of the pipe. 


The data held or collected about the assets can be divided into four categor¬ 
ies, i.e. Associated, Attribute, Knowledge and Pictorial; which is best shown 
by the example of a short length of pipe in the A27 trunk road as shown 
in Fig. 2. The information about the pipe is of two forms in the example, 
the spatial information which shows the physical location within space, that 
is the Easting, Northing and depth below the surface, and the attribute 
information about the pipe itself. Two examples of associated data are 
shown in this example, first the attribute information about the road, and 
secondly the attribute information about the land the pipe has been laid in. 
Both of these data sets provide additional information when considering 
say bursts or pipe material. For example pipes burst more often when laid 
in clay than in chalk. The physical construction of a pipe laid under a trunk 
road carrying heavy vehicles needs to be stronger than pipes laid within say 
a minor road or footpath. Within the attribute information references can 
be made to pictures, video images, or documents containing text. 
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Attribute information Spatial information 


j Attribute information 
I for road 



Fig. 2 GIS Architecture-Data Categories 


In order that improvements can be made all the information about the 
assets together with the associated information needs to be rationalised, 
integrated and maintained. A number of solutions exist to achieve this. One 
is to employ a large number of people to maintain the records and disperse 
them to all those that require the information. Although this may be feasible 
the integration and aggregation of data would be difficult. The preferred 
solution would be to computerise the information. One snag with com¬ 
puterisation is the quantity and type of data involved. Putting information 
into a computer is one thing but being able to retrieve and understand it is 
another, not to mention the cost of storing and maintaining it. 

In 1983 Southern Water initiated a feasibility study which in 1985 recom¬ 
mended a ten year program to build a computerised Geographical Informa¬ 
tion System (GIS) which would cover all aspects of the business throughout 
the Southern Water region. The GIS would be built incrementally over the 
period with each increment being subjected to a cost benefit analysis. It was 
also recommended that a pilot system be established for each major step to 
check that the requirement was correct as well as the cost benefit analysis. 
The Southern Water management of that day stipulated that any computer 
technology acquired for the phase 1 pilot system should be capable of 
redeployment for other tasks should the pilot demonstrate that it was not 
cost effective to proceed with a region-wide implementation. In 1985 tenders 
were let for the first stage pilot digital mapping system which was installed 
at Otterbourne in Hampshire for computerising the water records for the 
City of Southampton and the surrounding urban area, which is equivalent 
to 365 1:1250 Ordnance Survey(OS) map sheets. By 1986 the pilot had 
demonstrated that the first phase, that of data conversion, was feasible and 
that the specification and the cost benefit analysis were correct. In 1987 the 
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Southern Water board approved the implementation of phase 1 region-wide, 
as part of a Management Information System Strategy (MISS) that included 
as a subsystem the GIS and the integration of the regional telemetry system. 
The first phase was to convert all the water and sewer records to the digital 
mapping system. 

In 1989 the phase 2 pilot was approved, that of building a prototype of the 
asset database and linking the digital mapping system to it. It is expected 
that phase 2 will receive approval for full implementation towards the end 
of 1990. 

3 The Chosen Solution 

For GIS to be effective the information must be accessible wherever the 
employee is located at the time the need for the information arises. The 
phase 1 implementation has established the information within the first line 
water depots. Phase 2 will include all main offices and drainage depots. 
Subsequent phases will extend the access to the field employees’ homes 
where required and to a vehicle. The extension to the vehicle will require 
the integration of the corporate electronic mail system with the digital radio 
system. This integration is one of a number of parallel activities which when 
all have been implemented will make up the Water Services Management 
Information System. 


The computerised system must allow for incremental development and be 
able to deal with the requirements arising from converting the work force 
from localised standards to a corporate standard and ultimately to a national 
standard which would then allow utilities to electronically interchange and 
interpret information in a coherent way. The computerised system as always 
must be equal to or better than the existing system otherwise the average 
employee will not use it. The paper records had a data currency ranging 
from 3 months to 25 years or more, where currency is defined as “how up 
to date are the records in reflecting the real world system in any one 
particular time frame?”. For phase 1 of the project the target was set at one 
month. This may sound rather relaxed but it means that any permanent 
change that has occurred on the real world system must have been included 
within the computerised system located in the first line depots and that any 
paper records produced from those systems for field operatives shall have 
been produced and despatched within one month, that is 20 normal working 
days. The ten year target is to reduce this to 24 hours once integration of 
the telemetry system and vehicles has been accomplished. 


The decision was taken to convert the records to the computerised system 
“as is”, but with an accuracy or quality flag attached which would indicate 
the status of the information, such as unreliable, surveyed, etc. Converting 
the records as they existed was not considered to be a detrimental step as 
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once on the computer the records could be amended with ease. Accuracy is 
defined as “the exact location in space for all assets to within the nearest 
centimetre”. Here again, improving the accuracy of the information was 
considered a long task and may take over 100 years if the current manual 
practices are adhered to. By the end of this decade it is expected that 
technology will become available to assist with this task. 

A further requirement of the system was that of converting or capturing 
data at the lowest resolution which for a pipe would be for each individual 
length of which in any one street there may be many. However the com¬ 
puterised system must allow the aggregation of pipe lengths such that the 
pipe running the whole length of a street or between valves can appear as 
one pipe if this is required by the viewer. This is a facility which exists on 
the paper records but is not immediately apparent to the viewer. 

Different job functions require information once requested to be delivered 
or displayed at different speeds. For phase 1 the specification was set at 5 
minutes or less. 5 minutes was established as the mean time it took a water 
inspector to locate the maps required from the filing cabinets, copy them 
and invariably glue portions together as the paper records are not a continu¬ 
ous mapping system but made up of discrete tiles of say 500 metre squares 
that is 1:1250 OS map sheets, or one kilometre squares, that is 1:2500 OS 
map sheets. Again 5 minutes sounds a long time but it was still a tight time 
when one considers the amount of information that had to be retrieved, 
painted on the screen at the required scale and then put out to paper for 
use in the field. The 10-year target is to reduce this time to 5 seconds. 

The type of data that has to be displayed ranges from alphanumeric data, 
with which most people are familiar, via TP systems, textual information 
such as that entered from Office Systems such as ICL’s Office Power, through 
to raster data (pixel images) for displaying sketches, builder’s plans and OS 
maps that have not yet been digitised, vectors for drawing the pipes and the 
various attachments, as well as the digitised OS maps, video images from 
either the CCTV surveys or real time remote scanning to annotation of 
documents by voice. The specification was for each data type to be displayed 
either combined or singly within concurrent windows on the screen if re¬ 
quired in colour, where applicable. 

Due to this range of data types it is clear that computerising the data and 
storing it in a structure that enables fast processing, retrieval and display is 
pushing the boundaries of today’s computer technology. Table 1 shows the 
relationship between the Data Categories and the types of data. 

The quantity of data to be converted and captured is large and will take a 
number of years to achieve, by which time the database management systems 
will have developed to hold GIS data. 
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Table 1 GIS Architecture Relationship between Data Categories and Type of Data 


Type 

Associated 

Attribute 

Knowledge 

Pictorial 

Alpha-numeric 

* 

* 

* 


Raster 

* 

* 


* 

Text 

* 

* 

* 


Vector 

* 

* 


* 

Video 

* 

* 


* 

Voice 

* 





To convert the water and sewer records for a land area of 10,500 square 
kilometres with the population density as in the Southeast of England, using 
30 people, will take approximately 3 years. To capture the attribute informa¬ 
tion to the depth required at a rate that is cost effective will probably take 
5 years. As the data is being computerised the data will then need to be 
integrated with the other data sets which in itself will trigger off a data 
rationalisation process. Throughout the 10 year period the data will undergo 
continual rationalisation due to the need to remove historic reference keys 
used in previous systems, exploiting improved methods of storing in¬ 
formation, converting graphical or pictorial data into objects, and lastly to 
enable automated maintenance of the data to occur. This is summarised in 
Fig. 3. 



Fig. 3 Data Related Activity Profile 


During the first 3 years data definitions will be set up, which currently 
stand at 800 definitions plus, and then the business rules or knowledge base, 
which together enable the integrity of the data to be maintained, will 
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permit the automatic updating process and exception reporting to be imple¬ 
mented. 

The growth in data as shown in Fig. 4, for a minimum set of alphanumeric 
information about the assets, is estimated to be of the order of 30 to 40 
GBs. This would describe the pipework both spatially with the attribute 
data, the connectivity of the pipework, the connectivity to the property and 
the customer within the property, and in terms of performance, that is data 
about the flows, quality, pressure, bursts, etc. When the OS data for the 
region is added to the spatial database the total data stored would be in the 
region of 60 GBs. It is estimated that the GIS database would home in after 
10 years at the 100 GBs level. If the video images, textual information and 
rule base are added the data storage is estimated to be in the thousands of 
GBs. 


Fig. 4 



4 The Human Interface 

If collecting, storing and maintaining such quantities of data is to be cost 
effective the data should be used regularly by the widest number of employees 
possible. It is therefore paramount that the interface to the data is easy to 
use, easy to understand, and can be used without reference to manuals or 
online HELP systems, that is an intuitive interface. The forte of GIS systems 
is that they exploit pictures or images as a window on to the data which, if 
combined with the ability to issue instructions or data selections by pointing 
or preferably speaking, will bring the interface into the realm of the everyday 
human thought and decision-making processes. 

With today’s technology one can achieve the display of pictures, albeit not 
as fast as the brain’s visual processes, pointing by use of a mouse for high 
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resolution selections, or perhaps touch screen for low resolution selections, 
with minimal use of the keyboard. Different functions within the interface 
may call upon different applications behind the interface and it is imperative 
that a consistent “Look and Feel” is maintained across applications if 
confusion is to be avoided or minimised. The interfaces where possible 
should encapsulate the job function of the employee logging onto the system 
and should permit adaptation by the employee within the bounds of the 
data access rights set for a particular job function. For example if an 
employee is involved with one particular sewer catchment area there is little 
point in offering the ability to select any of the 400 plus sewer catchment 
areas and the 138 water distribution zones throughout the region. 


To display the picture requires facilities such as a gazetteer to be included 
in the interface which would contain street names, property names, local 
names, business related names, or employees’ personal names for localities 
or premises. Selection by OS map reference number or an Easting and 
Northing, (both of which are references from a position East and North of 
a point situated to the west of the Isles of Scilly), are transient methods 
provided in the main for conversion purposes; they are after all not a natural 
reference system for the everyday display of data. The GIS displays data as 
a continuum in that the viewer can pan across the surface of the earth 
without interruption as well as zoom into or out from the surface of the 
earth. As the viewer zooms in, ever greater detail can be displayed if required 
and as the viewer zooms out the finer details are dropped from the display. 
The viewer is even provided with the unnatural facility of panning and 
zooming under the surface of the earth! All of these functions are akin to 
moving one’s head or walking towards or away from an object; an interface 
containing such facilities could therefore be considered natural and thus 
should be easy to use. Again speed of operation is very important if this 
easy interface is not to frustrate the viewer. 

Utility services laid under the ground are located within a multi dimensional 
space that is x, y, z, t, etc; where x is the Easting, y is the Northing, z is the 
Height, t is time, all of which can be positive or negative. For example 
the flow in sewers is in the main by gravity which is achieved by laying the 
sewers with an incline. In the future the requirement exists for the multi¬ 
dimensional view of the sewer to be displayed especially at complex road 
junctions where many utilities services converge. The raster display of the 
ground is a more natural method of display than that of vectors thus the 
system needs to be capable of displaying and processing “pixel” images; this 
has the added advantage that it enables satellite technology to be exploited 
in the future. 

The interpretation of data can be greatly assisted by the use of colour or 
grey scales as differentiators. The ability to interpret information displayed 
is faster by the use of an area infill of colour rather than the colouring of 
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specific features. For example the Water Controller for Brighton may be 
interested to observe the current water pressure throughout the Brighton 
water distribution system and therefore asks the GIS system to display the 
pressure map. At least two methods could be used, to colour each individual 
pipe length with a colour representing a pressure band, or for the system to 
translate the spot pressure information into pressure zones, isobars or poly¬ 
gons and to in fill these polygons with colour. The latter method is un¬ 
doubtedly faster to assimilate but requires powerful technology in 
comparison with the first. The second question the controller may ask the 
system is to display those areas where the pressure is abnormal or out of 
limits; again the system uses a different colour to attract the viewer’s atten¬ 
tion to the areas concerned. This simple query has been used to demonstrate 
the various methods of display which have an impact on speed of assimila¬ 
tion. Again the eye finds it easier to assimilate blobs of colour than lines of 
colour. To accommodate both methods requires display technology that has 
a high resolution, a large colour palette together with the ability to display 
a large number of colours concurrently. The number of colours that can be 
used side by side is small when the quantity of information displayed in a 
geographical area is dense and when using colours for line work; this is not 
the case when colour infill is used. 


From this brief review of the interface requirements it is clear that the 
technology required must involve powerful computers, with good graphic 
display capability that can handle vector, raster and video formats, large 
attached disc capacity and good networking. Due to the need for the system 
to be built incrementally the technology involved must have a strategic 
development path that matches Southern Water’s GIS build program. 

From the outset the decision was taken to acquire workstations that had 
the ability to deliver the responsive system required and that the operating 
system should not be proprietary but UNIX. 

5 System Selection 

During the period 1983 to 1985 a number of manufacturers’ workstations 
were evaluated which included PERQ, APOLLO, SUN, HARRIS, PRIMA- 
GRAPHICS, etc; of these the SUN Microsystems offering was preferred 
due to the openness and the planned forward strategic path. In 1985 when 
Southern Water went to tender for digital mapping phase 1, 22 companies 
responded of which only three offered a solution based on general purpose 
workstation server architecture; of these only two offered a UNIX based 
solution. 


None of the bids at the time offered a solution based on SUN Microsystem 
equipment which probably was due to SUN being new to the market place. 
The remaining 19 digital mapping applications were based on time-shared 
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mini computers, and the majority of these applications could not support 
raster data. The mini-based solutions were not as modular as required and 
also came in more expensive than the workstation based solutions. It is 
interesting to note that of these 19, the majority of whom are still trading 
in the Digital Mapping GIS market, nearly all now offer applications systems 
based on networked UNIX workstations and servers. 


The contract in 1985 went to ICL for the hardware and ALPER Systems 
of Cambridge for the digital mapping software. The ICL hardware offered 
was the AGW3300 which was under development at that time. ICL supplied 
in early 1986 PERQ 2 hardware with attached Metheus colour screens as 
an interim measure pending the arrival of the AGW3300 in the summer of 
1986. In the event ICL terminated the development of the AGW3300 in 
July 1986 after investing in excess of nine million pounds on its development 
and instead chose to sell SUN Microsystems workstations and servers as an 
added value reseller. So more by luck than by design Southern Water ended 
up with a digital mapping GIS solution based upon its preferred workstation 
server platform that is SUN. By the summer of 1987 all the interim PERQ 
2 systems had been replaced by SUN 3/160C workstations and servers. By 
that time the pilot system in Hampshire had demonstrated the feasibility of 
Digital Mapping. 


The conversion from PERQ to SUN went well; the majority of the work 
was that of transferring the application from PNX to SUNOS. The most 
noticeable difference once the switch had been achieved was that the SUNOS 
communications software was far more resilient than the PERQ PNX 
offering. The performance of the system also improved together with the 
added advantage that the number of software and hardware problems fell 
dramatically. So the move proved to be beneficial and the results of the 
change confirmed Southern Water’s original workstation evaluations and 
benchmark results carried out prior to 1985. 


6 Achievements 

From 1988 the region-wide implementation of digital mapping for the prime 
purpose of “data conversion” commenced. Four implementation teams were 
established in each operational division, and became part of the division 
reporting to the Divisional Manager. These teams were provided on the 
mainland with seven SUN 3/60C workstations attached to a SUN 3/260 
server with one gigabyte of filestore and an EXABYTE drive. The peri¬ 
pherals included three CalComp A1 digitisers, a CalComp 5836 electrostatic 
plotter with an automatic paper cutter attached, a CalComp Colourview 
plotter which could either act as a screen dump device or as an A3 electro¬ 
static plotter. The prime purpose of these implementation teams was to 
convert first the water distribution records and then the sewer records. The 
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team on the Isle of Wight was somewhat smaller than the mainland divisions 
with only three 3/60C workstations. The number of staff involved was 30, 
none of whom were IT people or IT literate except for the managers. The 
managers were recruited from the operational side of the water business, 
that is they were previously performing such job functions as Water Control¬ 
lers, Sewer Catchment Managers etc. 

The integrated digital network which was already in existence was extended 
to the first line depots as shown in Fig. 5. The objective here was firstly to 
provide enough capacity such that files containing raster or vector maps 
could be despatched around the organisation with the minimum of delay 
and secondly to enable the divisional implementation teams and the IT staff 
based in Brighton to support the systems remotely that would be installed 
in the Water depots. 



Fig. 5 Data Communications Infrastructure 


All four operational headquarter campuses had all the buildings intercon¬ 
nected using fibre to create a campus-wide local area network, each of which 
were then connected to the wide area network using OSLAN bridges operat¬ 
ing at 64 kilobits per second; some were operated at 256 kilobits per second. 
These were changed on the main bearers in 1989 to the 2 megabit per second 
OSLAN bridges. The end result was one organisation-wide “ETHERNET” 
network carrying both OSLAN and TCP-IP traffic. 


Attached to the “ETHERNET NETWORK” are 73 systems which have 
the UNIX software mounted as shown in Fig. 6, over 120 SUN workstations, 
with the ICL DRS systems supporting 200 plus M303 dumb screens and 82 
Model 30 MSDOS heads. The 122 SUN workstations are used for civil 
engineering design using PAFEC “DOGS”, Water Resource modelling in¬ 
cluding above- and below-ground and estuary modelling using UNIRAS 
graphics software, water and sewer network modelling, engineering sur¬ 
veying using MOSS, as well as digital mapping. 
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WORKSTATIONS 


WORKSTATIONS 



WORKSTATIONS 

(M30) 


Fig. 6 UNIX/VME Configuration April 1990 


All SUN workstations have a high-level window environment installed, 
produced by IT Southern which enables the running of applications, admin¬ 
istrative facilities, electronic mail, etc and ensures that the persons using the 
SUN workstation, once they have identified themselves to the system, can 
work entirely by the use of the mouse if they wish. 

Over 31 GBs of filestore, which is made up of over 70 physical discs, is 
attached to the 32 SUN servers. The data on this filestore is protected by 
dumping the entire disc to tape each morning at 0200 hours automatically. 
During the working day the system prompts the local staff to load a normal 
SUN cartridge tape and an EXABYTE cartridge tape into the SUN cartridge 
and EXABYTE drives respectively. The system checks that the correct tapes 
have been loaded, and if not prompts the staff to correct the situation. After 
the discs have been dumped to the EXABYTE tape which can hold approx 
2 gigabytes of data, the log of the dump is transferred to the VME mainframe 
by the use of the file transfer facility. Once VME has received the logs, they 
are scanned and exception reports are produced if required and despatched 
to Technical Support for action to be taken. The VME system then files the 
logs for subsequent reference. The use of the EXABYTE tape drives has 
given significant savings in the time to dump and restore, storage space for 
tapes, reduction in the cost of the tapes and lastly minimised the time the 
system is out of use. The installation of the dump tapes daily is the only 
administrative task, staff in the depots have to perform. 


Of the 122 plus SUN workstations 45 are for digital mapping which are 
connected to 16 servers as shown in Fig. 7. The communications traffic 
between the SUNs is TCP-IP and OSLAN when they communicate with 
the VME mainframe services. 
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Each digital mapping workstation has either 8 or 12 MBs of memory and 
runs the ALPER “RECORDS” application. 

By the spring of 1989 the implementation teams had completed the conver¬ 
sion of the water distribution system to the digital mapping system and the 
data could be deployed to the depots. 19 SUN 3/60C workstations and their 
associated servers were installed in the first line depots during the summer 
of 1989. The filestore on these systems was either one gigabyte or two 
gigabytes dependent upon the geographic area served. Each geographic area 
had its own data base which at this stage of the GIS build was the only 
copy of the database. 

The training of the depot staff was carried out gently over a number of 
months. During conversion of the water distribution data the paper records 
were taken on loan by the implementation teams, each map for a period of 
five days. Once the data had been converted to the digital mapping system, 
overlay techniques using a light table were used to pick up the obvious 
transcription errors. Plots of the converted map together with the original 
were then returned to the depot for correction or amendment. The depots 
were allocated 14 days to turn each batch round. It took one year to convert 
the 11,500 kilometres of water network, during this time all water depot 
staff were invited into the implementation team offices for “happy hours” 
where they were allowed to observe and play with the system. Water In¬ 
spectors were also invited in at regular intervals to perform quality checks 
for their patch. During this period the demand for the digital mapping 
system to be installed at the water depots grew to such an extent that the 
depot staff became impatient. When the systems were dispersed in the 
summer of 1989 each system was set up with a training database to enable 
training to occur and also for the water staff to play on a system where no 
lasting damage could occur. 

Water staff then went through a rolling two-day training course provided 
by the IT Training section. The course was held on site in order to have the 
minimum affect on the day to day operations. The operational experience 
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from this training period is that water staff can become comfortable with 
the system within four hours. After the formal training period the IT trainers 
withdrew from the depots. The team leaders from the Implementation Teams 
then performed a ten day period of “hand holding” after which the depot 
would be considered fluent. Subsequent refresher courses are run as the 
digital mapping system is enhanced and the GIS build program progresses. 
During the deployment over 170 operational staff were trained throughout 
the region. 


All system administrative and quality assurance tasks are performed on the 
depot systems by the Divisional Implementation teams who now have the 
dual role of first line support as well as carrying on with the conversion of 
the sewer records. 


The filestore attached to each depot system is used for a number of purposes 
as shown in Fig. 8. The swap space or virtual memory for each workstation 
is of the order of 45 MBs. The largest part of the filestore is utilised for the 
back ground data or OS map database holding a mix of vector and raster 
maps. The associated data is held on the VME system. 



Fig. 8 GIS Architecture 


The systems installed in the water depots vary depending upon the number 
of workstations or size of the depot. For small depots such as the one in 
Hastings in East Sussex the system is built around one workstation typically 
with one gigabyte of data held in two “shoe boxes” as shown in Fig. 9. 
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Fig. 9 Configuration 1 


For larger depots such as Broadstairs in Kent, where there are three worksta¬ 
tions a SUN server is also present, the work stations being disc-less as shown 
in Fig. 10. 



Fig. 10 Configuration 2 


With the two configurations shown for Hastings and Broadstairs the graph¬ 
ics can only be displayed at Hastings and Broadstairs. The ability to view 
the graphics remotely will be implemented in a later phase. 

To overcome the problem where two different offices have the requirement 
to display the graphics, such as in Southampton and Otterbourne in 
Hampshire, one location’s workstations remotely load the map background 
and the foreground databases across the network as shown in Fig. 11. 
UNIX and the programs reside locally. The SUN server in Otterbourne 
serves a number of disc-less workstations at Otterbourne as well as those 
at Southampton. The bandwidth allocated between Southampton and Otter- 
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bourne is currently one megabit. This method functions well and is accept¬ 
able as an interim solution. 

The quantity of software implemented for the GIS system at phases 1 and 
2 is large as shown in Fig. 12. The facility-rich combination of UNIX and 
VME supports a growing number of application systems. On the SUN 
workstations either the ALPER ‘RECORDS’ application, which is predom¬ 
inantly for data conversion, capture, and update or the ALPER ‘ENQUIRY’ 
application for viewing with minimal update facilities has been implemented. 
Also on the SUN workstations are applications which process field survey 
data entered from portable computers. An example of one of these is that 
for sewer manhole survey data, which besides processing the manhole data 
received from either a Husky Hunter or bulk data from a data preparation 
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Fig. 12 Software 
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bureau, generates the sewer network for passing into the asset database. 
The front end applications communicate with the back end databases via 
an ICL provided Application Control Program. 


On the VME system, the ICL ‘PLANES’ product [Quinn, 1989] has been 
used for handling the asset database, which includes network, spatial and 
property related data. The VME database is the master asset database and 
is loaded from the ALPER databases. PLANES could also be considered 
as a super directory as it links the asset data to other data, such as customers, 
meters, financial information, etc; Data is then aggregated into the ICL 
CUBIT application. The aggregate database for example is where polygons 
for catchment boundaries, totals for water zones, etc; are held. 


What this combination of software provides is a good first cut at the CIS 
build. A viewer can view a picture containing Southern Water information 
which has been integrated not just in itself but with other externally acquired 
data such as the OS Map, census data, etc; 


By pointing at a valve on a water distribution network for example the 
viewer can bring up a window containing say a detailed plan or picture of 
that valve, or connect to the VME databases via PLANES. The viewer can 
walk the network or the asset either from the front end or the back end; in 
other words they have been synchronised. For example starting from 
pointing at a sewer manhole displayed at the front of the system, connection 
can be made if the viewer wishes to enter (unknown to them) the asset 
database on VME, walk down stream towards the sewerage treatment works 
looking at the data as the viewer goes. On returning to the picture at the 
front it would now be displaying the sewerage treatment works the viewer 
had walked to. 

An important point to note is that the conceptual processes being addressed 
by the system builders are data integration and display. They are not in the 
main concentrating on the underlying products which are almost taken for 
granted. The system described has a reasonable response time considering 
what is involved and improvements have still to be made to rationalise the 
interface between windows, e.g. the front end applications heavily exploit 
selections by pointing with a mouse whereas the back end applications are 
all keyboard oriented. 


A large proportion of the data on the system is the background maps - 
background as no intelligent use is made of the data at this stage in the 
GIS build program. All OS data both the initial map file and all the Digital 
Field Update Service (DFUS) data, which Southern Water receives after 30 
units of change in the area concerned, arrive from the OS and are put onto 
a database on the VME system. Currently over 6500 digital OS maps have 
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been acquired with a monthly inflow of approx 120 new maps For DFUS 
the inflow is typically of the order of 35 per month. This is as one can 
imagine a considerable investment in itself, the OS data acquired for the 
region to date having a current replacement value of three quarters of a 
million pounds. For this reason the VME system is considered to be secure 
and a well controlled environment to store this data in as the master set. 

Raster maps are produced in house by the Sussex Implementation team. 
Raster maps are made from good paper or film OS maps. Over 6000 raster 
maps have been produced and are held on the SUN map databases. The 
production rate for raster map units, at the peak data conversion point in 
late 1988, was of the order of 60 per day. Once produced they are despatched 
to the appropriate Implementation Team Supervisor, who has the responsib¬ 
ility of generating the required maps from the VME master OS data set and 
placing either the vector or the raster map into the appropriate SUN system 
map database. The communications system is using VME IPA facilities 
between VME and SUNOS, and SUNOS facilities between SUNs. This is 
summarised in Fig. 13. 


Regional 

os MAP DATA Supervisor 



Fig. 13 Ordnance Survey Data Flow 


7 Conclusions 

The phase 1 implementation of the GIS has been successfully implemented 
across the Southern Water region at each of the locations shown in Fig. 14. 
As the sewer data is converted further deployments will occur as part of 
phase 1. 

The quantity of data converted or acquired and loaded into the various 
databases is substantial and contains 580,388 features (excluding the OS 
map features) within an equivalent land area of 3897 sq kms. The data is 
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• Divisional HQ 
■ Water Depots 



Fig. 14 IT Southern - Principal locations 


held at nine locations on 11.7 GBs of filestore. The water data converted to 
date does not include the connection pipes between the water main in the 
street and the property, but only the water distribution system itself together 
with the trunk mains. The length of pipe as computerised is 12,121 kms 
which is different from that which Southern Water thought it had, namely 
approx. 11,500 kilometres; nevertheless there is a good match. 



Display of a map on the screen of a SUN workstation (Photo by Walter Gardiner Photography) 
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The reliability and availability of the system is very good, which is a tribute 
in itself to all the various parties involved, many of whom are unaware that 
their technology is being used in the way it is. 

The system described is no doubt both large in all aspects as well as complex 
and utilises a substantial amount of technology. The size and complexity 
however is not perceived or commented upon by the 170 plus operational 
staff using the system daily. Initially these staff were thrilled and very happy, 
but now they have become used to the system they are demanding more 
GIS facilities, a more responsive system and are frustrated because the 
system providers cannot deliver their requirements at the drop of a hat. 
There lies the challenge! It however does confirm that the complexities have 
become transparent and that this form of technology can be used by the 
average man and woman in the street. 
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Appendix 


A number of the names used in this paper are registered trademarks; 
these, with their owners, are as follows. 


APOLLO 

dbase II 

ETHERNET 

EXABYTE 

IBM 

PERQ 

POSIX 

SPARC 

SUN 

SUNOS 

UNIX 

X/OPEN 


Apollo Corporation 
Ashton-Tate Inc. 

Xerox Corporation 
Exabyte Corporation 
IBM Corporation 
Three Rivers Corporation 

The Institute of Electrical and Electronic Engineers 
Sun Microsystems Inc. 

Sun Microsystems Inc. 

Sun Microsystems Inc. 

AT&T in the USA and other countries 
X/OPEN Company Ltd. 
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Using Constraint Logic Programming 
Techniques in Container Port Planning 

Martin Perrett 

International Computers Hong Kong Limited 


Abstract 

This paper deals with the problems of resource management within 
a large container terminal. It describes a system developed at Hong 
Kong International Terminal (HIT) the largest privately owned con¬ 
tainer terminal in the world. The paper deals with the techniques 
and tools used in the development of the system in particular the 
use of ICL’s DECISIONPOWER incorporating a constraint logic pro¬ 
gramming language. 


1 Introduction 

This paper describes the problems of scheduling ships and managing re¬ 
sources within a large container terminal. It describes a system which has 
been designed and implemented at Hong Kong International Terminals 
Limited (HIT). A particular problem with which this yard is faced is the 
optimisation of land resources on which to store containers and so a major 
function of the system described is to make the best economic use of storage 
space. In solving these problems a revolutionary new software tool called 
DECISIONPOWER was used. This tool combines the declarative aspects 
of Prolog with the efficiency of constraint solving techniques. It is in effect 
a logic representation of a problem using constraints in an a priori fashion. 
This technique leads to greater control over the scheduling process and 
permits a more efficient use of resources. The system developed at HIT 
optimises the use of yard space and berths while allowing the user to override 
its decisions as judgement dictates. 


The system works by defining the problem in terms of constraints on the 
total problem search space. Example of constraints include: ‘Roll on Roll 
off vessels must be berthed at berths 4 or 6’, or ‘There must be at least 25 
metres clearance between any two berthed ships’. These constraints are used 
in an ‘active’ way to find a optimal solution where ‘optimal’ has been defined 
as a function to be minimised. 
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2 Planning Issues 

The container terminal currently (November 1990) has six berths in which 
to place the 300 ships per month that arrive and it has to allocate space to 
the many thousands of associated containers (see Photo). The planning 
problem is dealt with by two departments and broken down so as to be 
manageable using mainly human resources; the yard planning department 
manages the usage of the yard by allocating an area (called a Preferred Area 
or PA) for the use of the containers associated with each voyage; the berth 
allocation department allocates vessels to berths. A new terminal has just 
been opened at HIT which, with its extra berths and increased space, makes 
the planning task significantly more complex. 

2.1 Berth allocation 

In order to make the problem manageable, berth allocation was formerly 
performed 2 or 3 days in advance. Maximum usage of the berths was 
ensured by allocating as many vessels onto each berth as would fit, taking 
into account vessel lengths and statutory clearance. For the berthing depart¬ 
ment minimising the time at HIT (waiting time and time on berth combined) 
for each vessel was and is the top priority. Hence resources allocated to the 
ship (such as cranes) would be varied to maximise the usage and ensure that 
the vessels were not kept waiting for lack of resources. 

2.2 Yard planning 

The yard is organised so as to minimise the time taken to move containers 
on (and oflf) vessels. This is to ensure that the vessel’s time on berth is 
minimised. Containers may arrive seven or even more days in advance of 
the arrival of a vessel. Hence HIT takes great care in allocating space in the 
yard. A number of factors are taken into account in planning yard usage, 
these include: 

1 Scattering: if containers associated with a particular voyage are scattered 
then more resources have to be allocated to ensure that delays do not 
ensue. 

2 Marshalling distance: it is important that the vessels are as close as 
possible to their associated containers. This is because if movement 
distances are large then the vessel will be delayed on berth. 

3 Clashing: if the resources allocated to two or more vessels in port at the 
same time were working in the same area then congestion may occur, 
delaying the vessels. 

The planning department allocates a preferred area for each voyage in 
advance for the vessel which should be large enough to contain all the 
associated containers. An optimal preferred area is chosen by taking into 
account all the relevant factors affecting the time taken to load (and unload) 
the ship. 
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3 DECISIONPOWER 


A system was designed to produce satisfactory solutions to these problems 
making use of DECISIONPOWER*. This software tool incorporates a new 
generation programming language CHIP which combines the declarative 
aspects and ease of programming of Prolog with the efficiency of constraint 
solving techniques. CHIP was developed from research at the European 
Computer-Industry Research Centre (ECRC) at Munich in West Germany. 
ECRC is owned by ICL, Bull and Siemens. 

Logic Programming (eg Prolog) is an attractive language for scheduling 
problems (such as the one at HIT). This is due to its relational form, its 
backtracking capability and its non-determinism. The relational form is a 
convenient way of expressing the constraints on the scheduling process; the 
non determinism frees the developer from explicit tree-searching and the 
backtracking capability is crucial for solving discrete combinatorial 
problems. 

Unfortunately most logic program approaches suffer from a major problem 
of inefficiency. This is because standard backtracking is undirected in that 
the whole search space is traversed in seeking a solution. 

A number of approaches have been taken to avoid this problem (eg [5,6]). 
The approach taken by CHIP is to use the constraints in the system in an 
active way to prune the search tree in an a priori fashion (eg propagating 
forward the effects of constraints as soon as possible). It does this by 
embedding the consistency techniques inside Prolog thus relieving the pro¬ 
grammer of concerns about them. Thus CHIP aims to combine the efficiency 
of ‘hand crafted’ programs with the ease of logic programming. 

For example consider the (unrealistically simple) problem of allocating ships 
to berths with just the following 2 constraints:- 

1 Length constraint. Ships cannot be allocated to berths that are shorter 
than the length of the ship. 

2 Crane constraint. For each vesel there is a contractual minimum number 
of quayside cranes which must be allocated to it. 

Now consider the case of allocating 3 ships to 4 berths as described in tables 
1 and 2. There are 24 different arrangements of ships to berths. Using the 
constraints given above CHIP immediately allocates Ship 1 to Berth 4; 
Ship 2 to Berth 3; and Ship 3 to berth 2 without any searching, whereas 
traditional AI techniques will tend to try very many of the available combina¬ 
tions before arriving at a solution. 


♦DECISIONPOWER incorporates CHIP (Constant Handling in Prolog). 
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Table 1 



Length 

Contractual number of cranes 

Ship 1 

550 

2 

Ship 2 

350 

2 

Ship 3 

370 

3 


Table 2 


Length 

Number of cranes 

Berth 1 

300 

3 

Berth 2 

400 

3 

Berth 3 

500 

2 

Berth 4 

600 

2 


There are facilities in CHIP not only to find a solution but to find an optimal 
one through the availability of a number of predicates such as minimise. 
Once a solution has been found that satisfies the constraints a new constraint 
is generated that ensures that any new solution must be better than the one 
obtained. For example suppose that the aim is to minimise a function f and 
that a value, A, is found for f. Then a new constraint is generated that f < A, 
and the search continues. 

4 Constraints 

There are essentially three kinds of constraints within the system:- 

1 Hard constraints', these are constraints that must always apply, for ex¬ 
ample the clearance between vessels must be at least 25 metres; stacks 
of containers must not be more than four high. 

2 Soft constraints: these are priorities which planners would like to hold 
but which can be relaxed if no solution can be found. 

3 Procedural constraints: these are constraints that are built into the search 
strategy (see below). 

The hard constraints fall into three categories: physical constraints such as 
restrictions and safety regulations (eg roll-on-roll-off vessels must be berthed 
in particular berths, draughts of vessels on berth 8 must be less than 10 
metres), contractual obligations and ad hoc constraints (normally user over¬ 
rides) generated by the user for a particular voyage such as the fixing of a 
berth or preferred area. 

Much work has been done on constraint relaxation (eg [3]). In practice we 
may have to decide not merely which constraints to relax and the extent of 
the relaxation, but the number of constraints which need to be relaxed and 
the best way of relaxing them to obtain an optimal solution. The CHIP 
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approach is to examine the relationship between the costs of relaxing con¬ 
straints, for example:- 

- Consider the following diagram (Figure 1) where A is the berthed ship 
and B, C and D are potential preferred areas (PA’s) in which the container 
density at B would rise to 98%, at C would rise to 85% and at D would 
rise to 92%. Consider next the following constraints:- 

• The PA should be as close as possible to the ship 

• Container density should be less than 90% 



Fig. 1 Illustrating the choice of a preferred area for containers. A = ship; B, C & D are 
possible areas 


Table 3 



Distance 

Density 

Total 

B 

0 

10 

10 

C 

10 

0 

10 

D 

3 

3 

6 


Preferred area B obviously conforms to Cl but does not satisfy C2. C 
conforms to C2 but not to Cl. PA D on the other hand conforms to neither 
but may on examination of the costs involved prove the best solution. Yet 
D may be a difficult PA to obtain using an ordered relaxation technique 
where a list of the order of constraints to relax is kept. The approach 
adopted to these soft constraints is to represent them in cost tables (eg table 
3) and build the costs associated with the selection of a particular PA into 
an optimisation function. This has a number of advantages in that it allows:- 

• Degrees of relaxation 

• Comparison between constraints 

• A little of a lot’ as well as ‘a lot of a little’ (ie a comparison of the 
effects of small relaxation of several constraints with the larger relaxation 
of the few). 
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In the case of HIT this approach works well as many of the soft constraints 
are constraints on distances, times and densities which are easily quantified. 
However the comparative costs involved in assessing the importance of 
constraints are more difficult to arrive at and involve a process of cost 
weighting, which is decided by the expert yard planners. The expert yard 
planners are able to easily modify the cost tables given the declarative nature 
of the representation. 

5 Strategy 

The intention of the system is to optimise the total efficiency of the container 
terminal whilst accepting the firm constraints (safety considerations etc). 
HIT schedules over 14 days setting a preferred area for a voyage before any 
of the containers arrive. To set the PA, HIT uses a set of receiving patterns 
which provide the percentage of containers which is to arrive at the yard 
on each day prior to berthing, and the yard is searched for the best location 
for an area, large enough to fit in the containers within the area at any time, 
taking into account all the relevant constraints. The vessel is berthed as 
close to the preferred area as possible. Every day the schedule is updated 
but, while the berthing schedule (that is the site at which the ship will berth) 
may change on each update the PA will normally change only in exceptional 
circumstances. Before each schedule the user enters manually any changes 
or ad hoc constraints to ensure that the system has up to date information. 

During the search for a schedule a number of techniques are used. The 
optimisation facilities of CHIP are used to find the best solution, but in 
addition a number of heuristic and procedural techniques cuts down the 
size of the space searched. It is the search for an optimal solution (rather 
than just a feasible solution) that distinguishes CHIP style solutions from 
some others (eg see [3]). 

6 Procedural techniques 

The system organises the search by first finding a preferred area for those 
voyages that have not already had them set. It then chooses the best berth 
for all vessels in relation to their PA’s using the distance from the PA as a 
soft constraint on the berthing. It will only consider changing the PA when 
it cannot then find a suitable berth, given the conformation of the voyage 
details. This ensures that a good solution is found without backtracking 
from the berthing into the preferred area setting. 

Procedural controls are used as a way of implementing certain constraints; 
for example it is regarded as crucial that ‘vessel clashing’ is avoid unless a 
preferred area cannot otherwise be found. Hence in a search for a PA, the 
system will first look for one that has no clashing and only if this is not 
possible will it contemplate one with clashing. 
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6.1 Optimisation 


The system uses the optimisation not only as a way of finding the best 
solution but also as a way of controlling the relaxation of soft constraints 
(as above), for example berthing a ship a long distance from its preferred 



Picture of a model of the Hong Kong terminals. In reality the number of containers stacked 
on the quay would be far greater than is shown. (Photo courtesy Hong Kong International 
Terminals Ltd.) 
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area against the disadvantages of delaying the berthing. This trade off 
procedure allows us to link and evaluate the preferred area setting, the 
berthing and the timings of the berthing. 

6.2 Heuristics 

Despite using constraints within the system in an active way and using 
procedural techniques, given the size of the problem, heuristic control of 
the search is still necessary (see [7]). Two examples should suffice to give a 
flavour of the types of heuristic used in the system. 

1 Berth searching is a technique whereby the closest berth to the preferred 
area is tried first but if there is a need to search further then the search 
is continued in order of proximity to the PA. 

2 Home berths. This is a system whereby certain berths were allocated to 
shipping lines based on statistical analysis of the number of ships berthed 
and containers arrived in a week. These are known as home berths. 
Although the home berths concept is no longer used as a means of 
determining berth allocation it is useful as a means of determining a 
reasonable statistical starting point for a preferred area search since it 
demonstrated a method of distributing shipping and containers evenly 
throughout the terminal. This gives a chance of an early solution to the 
problem of finding a preferred area which could then be used as a 
constraint on finding other solutions. 


7 Conclusions 

The system is used to produce yard planning information quickly both over 
the medium term (up to two weeks in advance) and in the shorter term 
(when for instance an unexpected delay causes a disruption to the operating 
schedule). The speed with which these plans can be produced permits the 
planners to compare the effects of different courses of action. 

Factors such as staff productivity and maintenance costs are improved by 
optimising the use of available resources. Improved efficiency in the handling 
of containers leads to reduced berthing and waiting times. This means 
substantial savings both to HIT and to its customers for whom delay is a 
direct cost. 

The advantages of using Logic Programming techniques in the scheduling 
and planning tasks within container ports have been shown. In particular 
using CHIP as a development tool allows tailored solutions to be provided 
which make use of the special problem heuristics whilst at the same time 
freeing the programmer from tedious explicit tree-searching. The advantages 
of this approach are that the development time of systems is short (a first 
working model was available within 5 weeks and the full system completed 
within 6 months) and the code is modifiable and extensible. This is due to 
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the fact that CHIP combines the efficiency of a specialist program with the 

facility of Logic Programming. 

(For a full introduction to CHIP and the whole area of constraint satisfac¬ 
tion problems see Pascal Van Hentenryck’s Constraint Satisfaction in Logic 

Programming [7]). 
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Locator - An Application of Knowledge 
Engineering to ICL’s Customer Service 

G. W. Rouse 

Office Systems Services - ICL (UK) CS, Stevenage, UK 


Abstract 

The paper describes how a system providing rapid diagnoses of the 
likely causes of faults in computer systems came to be conceived 
and, after some false starts, successfully developed. 

The scheme, now in operation, allows operators in telephone contact 
with users to interrogate them and decide how best to resolve com¬ 
plaints either by advising the customer immediately what remedial 
action to take or, if an engineer has to call, ensuring that he is 
qualified to deal with the problem and takes with him any parts likely 
to be needed. In conclusion the practical benefits of the system are 
summarised. 


1 Background 

ICL Customer Services (CS) provides, as a major part of its services, a 
hardware repair service on-site for many hundreds of types of computer 
hardware platforms and peripherals that have been delivered to ICL’s clients 
over the years. What ICL (UK) CS aims to achieve is a repair without a 
site visit if possible. If that is not possible then the aim is to send the right 
person, with the right part, to the right place to resolve the right problem 
first time and within target time. 

In the computer services business failure to achieve a rapid, first time repair 
can be not only significant but alarmingly costly in terms of the man hours 
spent in unnecessary travel, and time on site. There is also the cost of unit 
modules being returned for repair which are, in fact, found to be not faulty 
during pre-repair testing. This cost penalty is particularly aggravating when 
the system which is the subject of the failure report might well comprise 
fewer than ten exchangeable modules. 

ICL customers pay a maintenance premium in order that we maximise the 
availability of their computer systems. It is vital therefore that we get to site 
fast, clear the problem and depart quickly so that the customer can get on 
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with running his/her business. Most customers agree that if we can jointly 
get the system fully operational again without the delay incurred by an 
engineer travelling to site, that is a more satisfactory repair; provided of 
course, that the reported fault does not recur. 

2 Operation Overdrive 

In 1985 the Director of ICL (UK) CS, Roger Burrell, determined to attempt 
a leap forward in engineering service response times and productivity. There 
were numerous key driving actions which included the re-allocation and re¬ 
disposition of spares etc. 

As the, then. Manager Small and Distributed Systems Support, responsible 
for second and third line systems support activity, the author was tasked 
with producing tree-structured diagnostic manuals for twelve hardware 
product types. The challenge was to create the necessary knowledge base in 
eight weeks and for that knowledge to be distributed in a usable form to 
the, then, nine UK service desks. 

The author appointed a colleague, Mike S. Thomas, to lead teams of product 
experts drawn from eight of the ICL (UK) CS mainland Branches and from 
our own unit’s second and third line support staff to create the manuals. 
There was total commitment from all teams to the project. Manuals of high 
quality were produced and distributed just in time for the start of the 
Overdrive programme. 

The manuals failed to deliver the benefits we had expected from the skill, 
commitment and effort expended in their production. Worse than this was 
the fact that the most significant reason that they failed to deliver the 
expected benefits was that they were cumbersome and slow in use rather 
than because of any other major deficiencies obvious at the time. 

The diagnosticians at the chosen Branch Desks felt either that they knew 
better than the manuals or that they could get to a satisfactory diagnosis 
faster without reference to the manuals. This user resistance to the employ¬ 
ment of knowledge-based systems was an expensive but extremely valuable 
lesson which significantly coloured our later approach to the Locator project 
and contributed very significantly to its successful design and introduction. 
We recognised that maintenance of a paper-based knowledge system would 
be a major consumer of effort. In the event, since there was little feedback 
from the proposed users, in spite of a formal route and methodology having 
been put in place, the problem of control of updates and distribution never 
arose. 

3 ICL Adviser 

The next step taken by ICL (UK) CS was to commission ICL’s Expert 
System Development Group to computerise part of one of the tree-struc- 
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tured manuals, using their excellent Adviser expert system shell tool (Mitcalf, 
1988). The Adviser approach works well for many applications but after a 
fairly brief trial it was clear that it could not meet the requirement for a 
high speed user interface. It was essential that the system should keep pace 
with the dialogue an operator conducted with the customer. The reference 
just quoted gives more detail of the approach using Adviser. 

4 Locator 

The breakthrough we looked for came with a demonstration version of the 
Kent University hypertext system ‘Guide’ which had been delivered, with a 
‘Kent Tools’ suite, to the author’s Graphics Workstation Support unit at 
Kidsgrove. Guide runs on a Sun 3 Graphics Workstation and has the speed 
of response at the ‘user interface’ and the capability to display Image which 
are, in our view, the keys to the diagnostic operations necessary for Small 
Systems Support. 

The first step was to build a working demonstration to show management 
the power of the user interface based on Guide when running a simulated 
diagnostic session. The next was to get authority to spend some money on 
further development. Management were quickly convinced that the idea had 
potential; at the time senior STC/ICL management were beginning to look 
favourably on investment in expert systems. 

The next step after that was to develop the Kent Guide user interface in 
such a way that it would fit in, at least passably well, with our field 
operational procedures. It also had to be totally acceptable to the end-user 
diagnosticians as well as to our customers’ end-user contacts calling for 
service. It had also to demonstrate its potential to integrate fully with the 
infrastructures of both current and future command and control systems 
used by field service operations. 

5 Field Trial 

In July/August of 1988 we went to field trial, with a well developed and 
operationally usable Locator system, commissioned from Professor Peter 
Brown of Kent University. This ran on Sun Model 3/75 Graphics Worksta¬ 
tions, at two of our CS Branch Desks. The knowledge database, scripted 
by our own staflT and primed down on to each end user delivery system, was 
for the ICL 8800 word processor. The knowledge-base had been created 
using the ‘Guide’ editor for priming both text and help images. 

Now, to create a useable knowledge database there are three or four essential 
processes namely:- 

1 Creation of relevant knowledge scripts from information held by skilled 
staff. There are two processes here, first acquiring the knowledge from 
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the experts and then compiling the information in a tree-structured 
format. 

2 Having acquired the compiled information, it has to be input to some 
database accessible from the Locator delivery system (platform) in order 
to “prime” the system for operational use. (LTE handles all the above 
at once, but when the 8800 system database was constructed for a field 
trial, LTE was not available and the job had to be done the hard way 
using the ‘Guide’ editor.) 

3 Locator delivery platforms can be at a number of separate locations but 
often require much of the same information and some which is location 
specific. The database information is distributed on streamer tapes which 
have multiple files used to ‘prime the local databases’ selectively with 
knowledge trees appropriate to the products. 

The trial met its pre-determined criteria for success in full, having been 
carefully measured on all counts. Not only did it score very highly on 
diagnostic hit rates but also on its acceptability to the diagnostician users 
and to our customers’ end-users. 

6 Further Development 

It was only at this stage that we were prepared to ask the management of 
ICL (UK) to authorise further spending against our original budget for 
software development. In our specific application, namely creating a tree- 
structured database for fast information retrieval, the Kent Guide editor 
required a level of skill and knowledge of Guide structure. Sun GWS and 
Unix systems inappropriate for use by non-experts. Most of our ICL product 
experts knew nothing of Guide, Unix or Sun, nor should they have needed 
to know anything in order to construct a knowledge database in their 
specialisation. 

We therefore had a tree-editor designed and developed for the purpose by 
the STC AI Development Unit at Harlow. This fully interfaced with the 
very much modified Kent Guide System and was designed to be fully usable 
by product specialists having only minimal knowledge of the structure of 
Guide or of the Sun GWS or its Unix operating system. 

The HCI for this tree-editor is the subject of a companion paper by Kevin 
Lewis of STC Technology in this issue of the Journal (Lewis, 1990). 

Product specialists can be trained to use the editor to create the tree- 
structured logic of the knowledge database and to display the results of 
their work via the Guide interface in less than half a day. Image ‘help 
screens’ may be added to the database from scanned photographs, line 
drawings or text and additional text titling can be added to the ‘help’ images. 
In order to interface fully with any other ICL Systems a Remote Session 
Access (Tele Processing) interface was developed. This is capable of full 
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'Copy and Paste’ action between appropriate windows on the end-users’ 
SUN workstation system. 

7 The User Interface of Locator 

The following is a resume of the features of the Locator user interface which 
runs, typically on a Sun Model 3/75 with 4 Megabytes of store, 16 Megabytes 
of disc and a monochrome screen. 

The Sun GWS screen is near A3 size; imagine it to be so. In the Locator 
application it is divided into discrete windows as follows:- 

• Left A4 ‘portrait ’ is for Locator keywords, diagnostic trail and diagnosis. 

• The left A4 window can have an A5 landscape window superimposed 
on its bottom half with ‘help’ information. This can be image or text 
or both. The operator ‘buttons’ this window in and out at will. 

• Top right A5 ‘landscape' is for up to sixteen icons summarising calls in 
suspense, ie waiting to be resumed. The operator can suspend a call and 
“iconise it” at will. The operator can only resume an iconised transaction 
when the Locator screen is no longer busy with a current transaction, 
whether new or resumed. 

• Bottom right A5 landscape contains a window into the current ICL Field 
Services Command and Control system screens. 

Locator has been designed to interface, via the Remote Session Access 
(RSA) service, not only to the current field operations command and control 
system ‘CRISP’ but also to any currently foreseeable command and control 
systems under development. Because of the RSA strategy chosen and the 
power of the Sun workstations running SUN-OS, it is possible to log in to 
and to access concurrently any of the appropriate and available on-line 
corporate systems such as the software Maintenance Database MDB or the 
spares database MARS etc. 

In practice the command and control system window is rather larger than 
the A5 size previously mentioned, in order to cope with what can be a very 
busy 25 X 80 text display; it can, therefore, overlap the Locator screen 
somewhat. Foreground and background positioning of this window has had 
to be put under operator button control. 

The system is used by an operator (diagnostician) in an interactive dialogue 
with an end-user reporting a potential system malfunction by telephone. 
The operator listens for a keyword such as screen, disc, printer, system dead 
etc. in the responses from the end user, which prompts the next question 
from the operator. Selection and “buttoning” of the keyword, via a mouse- 
driven pointer on the screen displays a question and the next logical set of 
keywords to listen for... 
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The sequence should terminate after seven or so questions with a diagnosis 
of the problem and a proposed action either by the end-user, or by ICL 
field engineering. The action recommended is transferred from the Locator 
system window by using a ‘copy and paste’ facility into the command and 
control system window for action by local field engineering. Help screens 
are available to the Locator operator which may be image or text or both. 

A trail of the keywords and responses for each diagnostic sequence is 
displayed on the screen. If appropriate the operator can backtrack during 
the course of the dialogue and resume a forward sequence taking an entirely 
new path to a different end-point. Once the call is closed the diagnostic 
sequence is automatically archived to local disc for post mortem analyses, 
if and as required. 

A call can be suspended in flight and displayed with its call number and a 
brief message in an Icon indicating that the end user will ring back with key 
information at some later time. A new call sequence can then be commenced. 
Sixteen such calls can be suspended in this way; any of them can be re¬ 
opened at a later time starting from the point at which it was suspended. 
Restarting can occur days later if necessary though the practice is normally 
to be avoided. There is full functional capability available to the operator 
to backtrack etc. until diagnosis is complete, transferred by copy and paste 
action to the command and control system window and the call closed. 

8 Locator Tree Editor (LTE) 

The key to the viability of Locator is the LTE system for writing scripts. 
The minimum viable store size on a Sun 3 GWS running LTE is 8 megabytes. 
The system is highly ergonomic in operation and enables creation, display 
and amendment of logical trees by ICL product experts who need have no 
prior knowledge of Sun GWS systems, Unix or ‘Guide’ file structures. They 
must, however, be able to think logically and so create appropriate diagnostic 
information based on their experience. 

In practice the system enables such experts to create and input between 
thirty and fifty accurate questions per day in an iterative process of creation, 
via LTE, and display, via Guide. Very little operational training is required 
and the system can be fully mastered by most users in less than a day. New 
users can become competent in about two hours. 

The system is very popular with product experts writing scripts for the 
knowledge-base. Their only complaint is that it should go a bit faster. Given 
that our original criterion was to make LTE ten times faster and simpler 
than using the original Guide editor in the same application and that we 
over-achieved this objective by a factor of ten, we might question the original 
criterion. To make LTE go faster we need more than the current 8 megabytes 
of store per Sun GWS. To make it go significantly faster we would need up 
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to 16 Megabytes but this would not yield appropriate cost/performance 
benefits from the authoring process. 

9 Conclusions 

ICL (UK) now has more than 65 screens in operation, handling over 900 
calls per day in Office Systems, Retail, Mainframe peripherals and Networks. 


Experience has demonstrated that the system provides the following key 
benefits:- 


• Consistent, rapid and progressively improving approaches to diagnosis 
of problems. 

• Diagnostic hit rates 20%+ better than those achieved by the best 
human diagnosticians. 

• Improved utilisation of spares. 

• Knowledge once captured is permanently available. 

• It reduces the skill level required for first line fault ‘locate’. 

• It has a high synergy with other major systems, such as MDB, ENDB, 
MARS, TEXT etc, which may be used in support of customer service. 

• Operators can be trained in less than half a day. 

• Experts required to ‘script and prime the database’ using LTE can be 
trained in less than half a day. 


10 Thanks and Acknowledgements 

In acknowledging the many contributors to this enterprise, which has been 
increasingly widely supported in ICL, the following deserve special mention:- 


• The Locator development and trials team as follows: Mike S. Thomas, 
Des Meehan, and Brian Brough, all working part-time with valuable 
contributions from Rob Briggs, all based at Stevenage. Managers and 
Staff from Stevenage, Elstree, Bristol and Manchester also contributed 
to the Pilot and Field trials. 

• Roger Burrell Director ICL (UK) CS and Ed Pedersen his Services 
Marketing and Development Manager who got us the budget we asked 
for and enabled us to develop this leading edge system. 

• Professor Peter Brown and his team from Kent University for timely 
development of Guide modifications. 

• Kevin Lewis, Clive Hayball and the team at STC Technology, Harlow 
for timely development of LTE. 

• Pete Bolden and team from Bolden James, for timely development of 
the IPA (Communications) interface to Locator. 

• Alper Systems for their contribution to our Image capture experiments. 


552 


ICL Technical Journal May 1991 


References 


LEWIS, K. “Designing the HCI for a Graphical Knowledge Tree Editor: A case study in user- 
centred design”. ICL Tech J Vol 7 no 3 (This issue). 

MITCALF, J.D. “Knowledge Engineering as an Aid to the system service desks”. ICL Tech. 
J. Vol 6 no Ip. 57-63 1988. 

Further references will be found at the end of Lewis’ paper. 


ICL Technical Journal May 1991 


553 


Designing the HCI for a Graphical 
Knowledge Tree Editor; A Case Study 
in User-Centred Design 


Kevin Lewis 

STC Technology Ltd, London Road, Harlow, Essex CM17 9NA 


Abstract 

The paper describes the development of the HCI (Human Computer 
Interface) of a Knowledge Tree Editor. The existing expert system 
lacked adequate support for knowledge tree building, extension and 
maintenance. We were approached to build a tool to allow easy 
construction, editing and maintenance of a large knowledge tree. 

The customer’s requirement was for a sophisticated graphical editor, 
suitable for use by inexperienced users, but was somewhat clouded 
by differing opinions and expectations. The complexity of the require¬ 
ment suggested the need for rapid, iterative HCI prototyping and 
evaluation. The HCI design was selected from a set of alternatives, 
in discussion with potential system users. The final design was refined 
from the chosen option. 

We conclude that rapid, iterative prototyping of HCI alternatives, 
coupled with informal end-user evaluation, facilitates customer ac¬ 
ceptance and the construction of a usable system. The resultant tool 
has been in use for over a year, and has gained full acceptance 
from its users across several sites. 


1 Introduction 

The paper describes the development of the HCI of a graphical knowledge 
tree editor. A knowledge tree embodies an expert’s understanding of a 
particular domain in a question and answer format. Following a trail 
through a knowledge tree allows progressive specialisation toward the cor¬ 
rect answer, with which is associated a diagnosis of the problem. The editor 
was designed to enable the easy construction, editing and maintenance of 
such a knowledge tree. 

The knowledge tree is used in ‘Locator’, a system developed by ICL Cus¬ 
tomer Services to provide a graphical, easy to use diagnostic facility to 
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support their front line help desk service. The facilities provided by the 
original Locator expert system for constructing, editing and maintaining the 
very large knowledge tree were difficult to use, time consuming and did not 
provide adequate support for a knowledge tree of the size required by ICL. 

ICL Customer Services approached us to build a tool to aid the development 
and maintenance of the knowledge tree. We provided a tool called the 
Locator Tree Editor (LTE). 

2 Overview of Locator 

The Locator system provides a graphical hypertext based expert system to 
be used by a diagnostician at their front line help desk facility. Locator is 
mouse driven. The monitor screen contains sensitive areas of text which 
may be selected in order to display further, associated screens of data. 

The diagnostician can use Locator to follow a line of questioning about 
possible computer faults that a telephoning customer may have, to a point 
where a diagnosis of the customer’s fault is produced. Locator displays a 
trail of the questions and answers and allows the diagnostician to backtrack 
to previous questions. 

The diagnosis produced contains information which is used to select an 
appropriate course of action. This may be providing the customer with a 
simple solution over the telephone, or sending out an engineer to fix the 
problem. As the problem has been diagnosed before the engineer is sent 
out, little or no troubleshooting at the customer’s site is required, thus 
reducing the time taken to fix problems. This has the effect of reducing the 
equipment maintenance costs and improving the customer’s image of the 
company. 

The original Locator system did not facilitate the easy development and 
maintenance of the knowledge tree, as the editing features provided by 
Locator were difficult to use and time consuming. The support for main¬ 
taining a very large knowledge tree provided by Locator was not sufficient 
for the size of tree required to support the extensive ICL product range. 

3 Knowledge Trees and the LTE Requirement 

We were given the requirement of supporting an expert in an ICL product 
in the task of developing and modifying the large knowledge tree to be used 
by Locator. This problem statement is simple, but the solution required to 
solve the problem was complex. Therefore we needed to investigate the 
requirements for the editor thoroughly before proceeding with the HCI 
design. The biggest problem we faced during the project was that the 
customer did not have a clear vision of a tool that would support the 
required tasks. This made the design of the tool more difficult as there was 
no consensus on the anticipated functionality and the HCI. 
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We were provided with several example user-computer dialogues. The dia¬ 
logues provided were simplistic in their detail and coverage of the problem 
area, and did little to suggest a suitable HCI for the system. The dialogues, 
however, provided us with a basis from which to determine the facilities 
required in LTE. 

Before we could begin any HCI design, we had to understand the way in 
which Locator operated. The Locator knowledge tree represents the com¬ 
bined expert knowledge on maintaining and repairing a range of ICL 
products. This is structured as a number of topics, each of which may have 
a number of associated sections. For example, a topic could be the ‘Series 
39’ computer system. The sections associated with this may be: ‘Disc Drive’, 
‘Printer’, ‘Communications’ etc. Using this scheme, it is possible for a 
knowledge tree to cover the whole of the ICL product range in manageable 
topics and sections, each of which may be created and modified inde¬ 
pendently. 

Knowledge tree sections are displayed by Locator in two different formats: 
question screens and diagnosis screens. 

A question screen consists, from top to bottom, of an answer trail, specifying 
how this point in the tree was reached, a textual question, a set of answer 
buttons, and optional help “buttons”. The diagnostician can click with the 
mouse on an answer button, which causes Locator to display another screen 
with more questions and answers, or a diagnosis. Clicking on a help button 
opens a sub-window with a textual or graphical help message. 

A diagnosis screen is completely textual, and consists of the diagnosis, and 
a list of actions for each of a set of actors. In this application, the actors 
are ‘Customer’, ‘Diagnostician’, ‘Engineer’ and ‘Customer Services Repres¬ 
entative’. The diagnostician uses the information displayed on the screen to 
inform the customer of the problem, or to arrange for further investigation 
or fixing by an engineer. 

By understanding the different screens and their contents, we were able to 
form opinions on the nature of the HCI for LTE. This is described in the 
following section. 

4 HCI Prototyping 

The first task in HCI design was to define our user population. The anticip¬ 
ated user was an expert in an ICL product range or individual product. We 
were able to assume some experience in using computers, and, in particular, 
WIMP (windows, icons, mouse, popup menus) interfaces. This allowed us 
to employ a graphical display with which to interact with the user. In 
particular the ability to make use of the mouse to operate popup menus 
and buttons was very useful, as we were able to provide popup menus for 
each of the items displayed on the screen. 
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It was difficult to understand the user requirement in detail. We had only a 
sketchy brief from the customer upon which to develop the HCI. We decided 
to investigate the user requirements for the system by providing an HCI 
prototype which contained little or no deep functionality. This HCI could 
be presented to the customer and potential users for feedback and evalu¬ 
ation. Thus we proposed to use an iterative approach to the HCI design. 

We examined Locator to determine what knowledge tree objects we required. 
These related to the two Locator screen types. We distinguished four tree 
node types: question nodes, answer nodes, diagnosis nodes, and branch 
nodes. 

A question node contains the question text, and an optional help button 
reference. An answer node contains the answer text itself and the answer 
trail text. A diagnosis node contains the diagnosis text and, for each actor, 
a list of textual actions. The branch node contains the part of the tree to 
which to jump, when the node is reached in Locator. 

An analysis of the tasks the user might wish to carry out was performed. 
We discovered a number of facilities required in the system. These are noted 
in the task decomposition below: 

Initiative Editor 
Create New Tree 
Load Existing Tree 

Select Tree to load 

Edit Tree 

Add Nodes 

question, answer, diagnosis, branch 
Delete Node 

question, answer, diagnosis, branch 
Edit Text in Nodes 

question, answer, diagnosis, branch 
Cut, Copy and Paste Subtrees 
Navigate Tree 

View from Here 
View from Previous 

Run Guide 
Save Tree 
Quit Editor 

Most of the operations above do not need to be explained. Those that do 
are the navigation options and ‘Run Guide’. The ‘View from Here’ option 
causes the tree to display itself from the node on which the operation is 
performed. The ‘View from Previous’ reverts to a display one question level 
back. 
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‘Run Guide’ allows the user to see the effect of tree changes on the target 
Locator system. Guide displays the tree almost exactly as it would 
appear if it were running under the Locator system. (This is achieved as 
Locator itself is based on Guide, with a number of additions). The ability 
to ‘Run Guide’ becomes increasingly important as the tree approaches 
completion and the user edits the knowledge to ensure a good on-screen 
presentation. 

From the set of tasks, we were able to distinguish five distinct types of 
processes: 

Loading and Creating Trees -tree selection 

Editing Tree Structure -knowledge ordering information 

Editing Tree Data -the knowledge at each node 

Saving Trees and Quitting -tree update 

Running Guide -tree inspection 

We were now able to make an initial attempt at defining the screen areas 
with which the user could interact. The task structure suggested that we 
required an area to display the tree, a separate area to edit the text of the 
tree nodes, another to control saving and quitting, and a final, top-level, 
area where the user could create or load trees. Running Guide required 
another window. This window was to be modal, in that it would have to 
close before LTE would continue. 

A further customer requirement was for an ‘Audit Trail’ which shows the 
question-answer path of how the current question node was reached. This 
was to be displayed in another window. 

We had to make a number of HCI and development design decisions before 
proceeding to produce the HCI prototype. These included: 

(i) How should the knowledge he displayed? 

The data ICL were proposing to place in Locator was in a linear paper- 
based system, with jumps from answers to other pages in the document. 
When these documents were developed, the experts employed a tree structure 
to help understand the questions and answers. It seemed natural to use a 
tree structure in the tool as this closely resembled the current method of 
working. This is an advantage as the future users of the tool would not need 
to modify their thinking considerably. 

(ii) Should the tree display he horizontal or vertical? 

Again, the experts used a horizontal tree during development, therefore this 
is the one we chose. 
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(Hi) How to display the detail of the tree? 

As there were four distinct node types, we decided to display them uniquely 
to aid identification. We proposed to use different boxes and font styles to 
allow the user to distinguish between the node types. A question node was 
to display its number and the question text in a rectangular box. Its answers 
were to be linked by lines. The answer nodes were not boxed, but were 
emboldened to give them emphasis. The diagnosis node was designed sim¬ 
ilarly to the question node, except that the word ‘Diagnosis:’ and the 
diagnosis number were displayed in bold text in the box, along with the 
diagnosis text. The branch node was a smaller, round cornered box dis¬ 
playing the branch filename. 

(iv) How much of the tree should be displayed at any time? 

The problem arose because the trees were generally much larger than the 
screen area, and tree navigation became troublesome. We made the assump¬ 
tion that the experts worked with only one question level at a time. Therefore 
we proposed to display a root question, its answers and the nodes following 
the answers. The user could manipulate the whole tree level, and when 
required, move level up or down the tree as appropriate. This solution 
seemed most appropriate as it tended to focus the user’s attention toward 
the part of the tree on which he is currently working. 

(v) What tools should we use to develop this prototype? 

We required a graphical system which ran on the delivery vehicle (Sun-3), 
and that provided a set of facilities which allowed us to produce graphics 
quickly and easily. It was important to have a high degree of reusability 
throughout the system to encourage a consistent user interface. We chose 
to use a user interface development tool called PCE/Prolog (Anjewierden, 
1986) which has these features, and which we had experience in using. 

The use of PCE/Prolog allowed us to produce a prototype rapidly. The 
toolkit also allowed us to modify the window size and position on screen, 
and to record these for later use. This proved to be an invaluable feature 
during the HCI design as we were able to modify displays while the customer 
was watching, and to modify them to the customer’s liking. 

The first screen layout we designed is shown in Fig. 1. 

The second level of the tree is displayed in the right hand window, with 
different kinds of nodes. In addition to the different node shapes and 
contents, each type of node has a different popup menu associated with it. 
Each menu reflects the operations the user can perform on the node or 
subtree at that node. The figure shows the popup menu for a question node. 
The Audit Trail is shown with the entry for the first question and answer 
trail present. 
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Fig. 1 The Original LTE Screen Layout showing Popup Menu and Audit Trail 








































This screen layout was built into a prototype around which a simple ‘story’ 
was written. This was intended to demonstrate the proposed facilities in the 
tool. 

5 Results of HCI Evaluation 

After the prototype had been built, the customer was invited to comment. 
During the evaluation meeting, the customer and a senior user were present. 


This stage of the project proved to be the most important as major differences 
in expectations and interpretations of the HCI were highlighted. The most 
important problem highlighted was the apparent need for the user to be 
able to see as much of the tree as possible. In our scheme, only one level 
(one question) was visible at any time. In generating these knowledge trees 
by hand, a whiteboard is used to map out the structure and content of the 
tree, in order to be able to follow the reasoning of the questions and answers 
leading to the current tree position. Therefore, we needed to show more of 
the tree, as the user demanded. 


This raised a problem with the current screen layout because it was imposs¬ 
ible to see more than one question level at any time. During the evaluation 
session, we used the toolkit’s ability to resize and move windows to redesign 
the screen such that the tree was displayed in the window which was longer 
horizontally than vertically. This layout was closer to the customer’s wishes 
than the original design. At one point during the session, we used several 
monitors to display three different screen layouts. 

This helped the customer to see the advantages of each of the different 
HCIs. 


To aid the user in the navigation of the tree, two more facilities were added: 
Expand and Collapse. Expand causes the question node to display its 
answers and their children, thus revealing one more level of the tree. Collapse 
causes the subtree to fold into one greyed out node. These were very useful 
features which, together with the other commands, help the user to navigate 
the tree more easily. 


The final HCI design was chosen at this group meeting from one of these 
system alternatives. 


As the project progressed, it became clear that the customer’s initial unclear 
vision of the tool had now changed because of our prototyping activity, and 
that this vision was now converging toward our ideas of the proposed HCI. 
However, there was still scope for further refinement of the HCI. 
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6 Implementation of LTE and Use 

During the development, a number of minor HCI problems were resolved, 
in conjunction with the customer and users. These problems included issues 
such as ‘intelligent’ pointer positioning after the user had performed a 
particular operation, the sizes of data entry areas, and the provision of ‘hot 
keys’ to allow the user to quickly move the pointer between text areas. 

Several more complex features were requested by the users as their require¬ 
ments modified due to their increased usage of the tool which met almost 
all their needs. 

One example of such a feature was the ability to add more than one answer 
at a time. In the original design, the user was expected to choose the ‘add 
answer’ menu item from a question node for each answer. The users thought 
that it would be convenient to allow the addition of more than one answer 
at a time. This facility was designed and implemented and proved to be very 
beneficial to the users. 

Many hours were spent evaluating the usability and reliability of the tool. 
The reliability aspect became increasingly important as the development 
progressed, as some of the trees built during testing were intended to be 
used in Locator. The user’s trust in the tool was high by the end of the 
development. 

Several important points came out of the development: incorporating users 
into the software development life cycle ensured that the tool was usable: 
extensive testing ensured high reliability, and increased confidence in the 
integrity of the data the tool produced: involving the customer aided the 
installation and uptake of the tool adding to the success of the tool in 
the field. 

The final designed and implemented HCI is shown in Fig. 2. The design 
shows the same tree as the previous figure, of which more is visible. The 
data entry area is being used to edit the text of the third question node. 

7 Conclusions 

The LTE system was completed and finally delivered to the customer in 
February 1989. It rapidly gained user acceptance across three sites, and has 
since been used intensively with no problems. 

A highly usable HCI for the system was developed using rapid and iterative 
prototyping of alternatives involving both the customer and users. This in 
turn led to easy customer acceptance of and commitment to the tool and 
its widespread use. 
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Fig. 2 The Final LTE Screen Layout showing same tree and data entry area 






































The rapid and iterative prototyping approach was only possible with the 
use of a graphical toolkit. This allowed us to make substantial changes to 
the HCI quickly and easily. It also helped to ensure a consistent user 
interface across the tool. 

The continuing HCI evaluation by the customer and users was informal, 
but served extremely well to highlight problems as they arose, and to increase 
the usability of the tool. This emphasises the benefits of user participation 
in the HCI design process. 

Subsequently, equipped with only a User Guide, an ICL salesman learned 
to use LTE productively in only a single morning. The salesman praised the 
ease of use of LTE as the major factor in the short learning curve. 

Some time after the delivery of LTE, we received a letter from ICL Customer 
Services. The letter quantified the increase in productivity of the staff using 
LTE over the existing system. This increase was measured at over an order 
of magnitude improvement. This considerable increase in productivity was 
due to the constant involvement of the users throughout the development, 
hence showing the benefits of a user-centred design process. 
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Abstract 

An article in the November 1987 Issue of the ICL Technical Journal 
described the initiation of the X/Open Group in 1984 and its growth 
and achievements over the first three years. This current article takes 
the story on through the following three years, during which time 
X/Open''’'^ has grown to involve most of the major players in the 
IT industry worldwide, and has become a very significant driving 
and unifying force for the success of Open Systems. 


1 Introduction 

An article in the November 1987 Issue of the ICL Technical Journal de¬ 
scribed the initiation of the X/Open Group in 1984 and its growth and 
achievements over the first three years. This current article takes the story 
on through the following three years, during which time X/Open^*^ has 
grown to involve most of the major players in the IT industry worldwide, 
and has become a very significant driving and unifying force for the success 
of Open Systems. 

The formation of the X/Open Group in 1984 was the result of: 

a) a growing user resistance to the long term lock-in efiects of proprietary 
operating systems, 

b) an insufficient supply of generally available applications for these propri¬ 
etary systems, and 

c) the hardware technology evolution that lead to the emergence of cheap 
powerful systems which allowed the “Department” to become a large 
scale user of information technology. 

The Personal Computer explosion had highlighted the virtuous circle created 
by Industry Standards when the volume cost equations are favourable, and 
the same phenomenon was underway for the multi-user systems needed to 
support departmental operation. To achieve this a suitable generally avail¬ 
able multi-user operating system was required and many computer manufac¬ 
turers were turning to UNIX^*^, or systems derived from it and/or its 
interfaces. 
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UNIX was written in the C language and had been designed to be portable 
to different hardware bases; it also supported C as a language for writing 
applications. It therefore had the necessary potential for providing a com¬ 
mon operating system and common application language on a wide range 
of hardware. Unlike the PC situation which standardised at the hardware 
level (applications in binary), it offered standardisation at the source code 
level thus allowing the same applications to work across the wide range of 
different hardware architectures needed to cover the power range of Depart¬ 
mental systems (whilst still allowing the ability to define binary sub-sets 
where appropriate). However, although UNIX largely fitted the requirement, 
it had not been rigidly controlled with regard to standard interfaces, and 
several significantly different flavours were being developed and marketed. 


In 1984 ICL approached the other major European computer manufacturers 
with the view to forming a collaboration dedicated to ensuring not only 
that there would be a single standard at the UNIX level, but also that a 
complete Common Applications Environment (CAE) should be defined 
covering the basic operating system, data management, integration of ap¬ 
plications, data communications, distributed systems, high level languages, 
internationalisation, security and all the many other aspects involved in 
providing a comprehensive set of interfaces for portable applications. 


If this could be achieved it would be to the mutual advantage of Users, 
Independent Software Vendors (ISV’s) and the system suppliers. The Users 
would be freed from lock-in (investment made in applications, programmer 
training and operating procedures would be protected) and systems from 
different suppliers could be mixed and matched. The ISV’s would be encour¬ 
aged to produce applications, as they would run across a wide range of 
systems from many suppliers; and the system suppliers would benefit from 
the many applications available for their systems and the availability of 
operating system components as commodity items. Competition would move 
into more significant added value areas such as systems integration and 
industry specialisation. 

2 The First Three Years 

This section briefly recaps the first three years; the November 1987 article 
should be consulted for a full description. 


The collaboration was started in 1984 by Bull, ICL, Siemens, Olivetti and 
Nixdorf under the codename BISON, the objective being to develop a 
Common Applications Environment (CAE) by adopting, adapting and re¬ 
fining international and de facto standards. During the first year the initial 
phase of work was completed, and published in the “X/Open Portability 
Guide, Issue 1” (XPGl). Also during this period Philips and Ericsson joined 
the group and the name X/Open was adopted and registered. 
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The second phase saw a major influx of US companies (Digital, Unisys, 
Hewlett-Packard and AT&T), which was a measure of the early success, 
added significant strength to the Group, and widened the scope outside 
Europe. It brought the total number of members to eleven. At the end of 
this period the second issue of the Portability Guide (XPG2) was published 
approximately doubling the coverage of the CAE. 

The coverage of the CAE in XPG2 (Jan 1987) was: 

a) System Calls and Libraries 

b) Commands and Utilities 

c) C Language 

d) Internationalisation 

e) Terminal Interfaces 

f) Inter-process Communication 

g) COBOL 

h) FORTRAN 

i) PASCAL 

j) ISAM 

k) SQL. 

Also over this period a verification suite to test the conformance of systems 
to the X/Open definitions was developed, and significant work towards 
further evolution of the CAE was initiated. 

3 The X/Open Portability Guide - Issue 3 (XPG3) 

As described in the earlier article, the IEEE PI003 committee was working 
on a standard for a “Portable Operating System for Computer Environ¬ 
ments” which defined a set of interfaces largely based on (a sub-set of) those 
of the UNIX operating System. This standard, known as POSIX, had been 
issued in trial use form in April 1986. X/Open had expressed full support 
for POSIX and had declared intent to converge the Portability Guide with 
it when it achieved “full use” status. Since then the first phase of POSIX, 
or more precisely the PI003.1 standard, not only achieved full use status, 
but has passed on via ANSI into the ISO/IEC arena as ISO 9945-1:1990. 

The primary focus of the third issue of the X/Open Portability Guide 
(XPG3) was this alignment with POSIX, and timescale for publication was 
determined by P1003.1 ratification. In practice many further iterations of 
P1003.1 took place beyond the original trial use version, and X/Open was 
very active in this work. 

The other significant aspects of XPG3 were the moves into the graphical 
user interface area with the adoption of the foundation elements of the 
X-Windows System (the XLIB interface and the reference to the X-Proto- 
col), and into system interconnection with the introduction of the Transport 
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Interface (XTI). The latter provided a standard application interface to both 
ISO/OSI Transport, and to Internet (TCP/IP, etc). 

In addition most of the functional areas that were in XPG2 were revised, 
and in some places significantly enhanced. Internationalisation was both 
enhanced and further aligned with ANSI C and /usr/group (now renamed 
UniForum) definitions, and the basic interfaces were made a mandatory 
part of an XPG3 system. The ADA language was also added. 

“X/Open Portability Guide - Issue 3” (XPG3) was published as a seven 
volume set. Volumes 4-7 in August 1988, and Volumes 1-3 (determined by 
P1003.1 ratification) in December 1988. (Collectively they are often thought 
of as the 1989 edition illustrating the approximately two year cycle - 
XPGl 1985, XPG2 1987, XPG3 1989.) 

The contents of XPG3 are: 


Volume 1 
Volume 2 
Volume 3 


Volume 4: 


Volume 5: 


Volume 6: 
Volume 7: 


XSI Commands and Utilities 
XSI System Interfaces and Headers 
Supplementary Definitions 

- Internationalisation 

- XSI Terminal Interface (Curses) 

- Source Code Transfer 
Programming Languages 

- C Language 

- COBOL 

(Due to an editing error the definitions for ADA, Fortran and 
Pascal were accidentally omitted from this volume. They are 
given in the “XPG3 Portability Guide Overview”.) 

Data Management 

- ISAM 

- SQL 

Window Management - XLIB 
Networking Services 

- Transport Interface XTI 

- PC Inter-connection (rudamentary). 


Although not part of XPG3, an X/Open Security Guide was also published 
in this same timeframe. This well received document is a description of 
security issues, and gives much advice concerning the use of the security 
features to be found in most XPG systems and how to manage a secure 
environment. 


4 Growth of Membership 

During this period the full membership of the X/Open Group almost 
doubled (11 to 21), including the addition of some very significant companies 
and the extension to three major continents (Europe, USA and Japan). This 
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illustrated the impact that was being made and the rapidly growing import¬ 
ance of the operation. 

Three events are particularly noteworthy: 

a) the application and acceptance of IBM, 

b) the entry of the Japanese companies, and 

c) the membership of OSF and UNIX International. 

The 21 members were: 


Bull 

AT&T 

UI 

ICL 

Digital 

Fujitsu 

Siemens 

Unisys 

Hitachi 

Olivetti 

HP 

NEC 

Nixdorf 

IBM 


Philips 

NCR 


Nokia* 

SUN 

Prime 

Apollo 

OSF 



(*The Ericsson membership was transferred to Nokia Data on their acquisi¬ 
tion of the relevent part of the Ericsson operation.) 

These 21 companies represent most of the major IT companies in the world. 

Since the peak of 21 the numeric measure has reduced through acquisitions 
within the membership. Apollo has become part of Hewlett-Packard, and 
Nixdorf has been acquired by Siemens. This does not represent a loss of 
actual support for the X/Open process as the organisations involved are still 
within the X/Open membership. 

5 The X/Open Company Limited 

ICL initiated the X/Open collaboration, and up to September 1987 provided 
most of the extra resources needed to administer the Group. By this time 
the growth (actual and projected) in scale and scope was such that it was 
no longer sensible to continue in this mode and a separate company was 
established to support the operation. This facilitated the growth of the 
central function to match the increasing requirements of the enlarged mem¬ 
bership, allowed the scope to be widened to cover more than just application 
portability, and it re-enforced the independence needed for interaction with 
governments, major users and the software industry. The X/Open Company 
Limited was founded on 10th September 1987 with each of the Group 
Members becoming a Shareholder and having a seat on the Board of 
Directors. 
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The X/Open Company Limited has headquarters at Apex Plaza, Forbury 
Road, Reading, England, and additional offices in Connecticut, San Fran¬ 
cisco and Tokyo. At the time of writing its staff level is about 40 people. It 
is headed by the President and CEO, and is divided into two main functions. 
Technical, concerned with the development and publication of the actual 
standards, and Marketing, concerned with user requirements and the adop¬ 
tion of the X/Open concepts and standards by the IT industry. 

The creation of the separate company did not reduce the contribution of 
the individual members, who are still heavily involved through the Board 
and its sub-committees, the Technical Managers Group, the Marketing 
Managers Group and many Working Groups tackling specific topic areas. 
X/Open is a consensus organisation which means that all have the opportun¬ 
ity to determine the outcome, but once agreed everyone is committed. (The 
downside of course is that some agreements are difficult to achieve.) 

The user requirements gathered by Marketing, are input to the Technical 
function which then establishes workprogrammes to determine the standards 
required for specific topic areas. Most work programmes are carried out by 
Work Groups which are staffed by experts from the member companies, by 
X/Open staff and by consultants. The Technical Managers Group, which 
consists of the X/Open Chief Technical Officer and a representative from 
each member company and each Associate Member Group, oversees the 
technical programme within an annual budget set by the Board. It deter¬ 
mines technical strategy, establishes workprogrammes, acquires the neces¬ 
sary technical experts, and monitors progress against the plans. At any one 
time something like a dozen work programmes are likely to be active. 

This represents a very significant investment from the member companies 
both financially and in availability of highly skilled staff, and illustrates a 
great commitment to X/Open and the development of Open Systems. In 
financial terms, the annual membership fee for shareholders is currently 
approximately £350K, and, if the contribution of the Associate Members 
and all the manpower provided by the members at Board, MM, TM and 
work group level is taken into account, then a total of around $20M per 
year is probably involved. 

6 Councils and Associate Membership Groups 

Although X/Open shareholders are primarily system vendors, the objective 
is to vigorously develop and promote Open Systems to the mutual advantage 
of Users, Independent Software Vendors (ISV’s) and the systems suppliers. 
It was considered important therefore to ensure that the activity was really 
aligned with the requirements of the users and ISV’s. 

The first significant step in this direction was the creation of User and ISV 
Councils that would meet regularly and advise on the technical direction, 
major deficiencies and priorities for future X/Open work. They would also 
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be able to influence the proposed standards in advance of publication. The 
User Council was initiated in 1988 composed of senior representatives of 
large commercial companies and government procurement agencies. At the 
same time, the ISV Council was created with membership from well known 
major software vendors. 

During 1989 it was decided that this relationship, although very positive, 
was too much at arms length, and that a stronger one would be introduced 
providing a direct involvement in X/Open technical evolution in return for 
an active commitment from each member of the Councils to support the 
X/Open aims and objectives. Early in 1990 the Councils were therefore 
formally re-constituted as Associate Member Groups (AMG’s), that could 
each provide a representative on the Board, the Technical and Marketing 
Managers Groups and the various working groups. 

It was also decided to extend the AMG concept to cover other important 
groupings. The first of these, the System Vendor Council, has now been 
formed and gives a voice to the smaller system vendors who would find the 
cost of full membership prohibitive, or do not fully meet the acceptance 
criteria. 

These Associate Membership Groups, and the XTRA process described 
below, are very important, as X/Open is often described as a “vendor club” 
in a context that implies a very closed situation and parochial interests. In 
fact with X/Open, the users, ISV’s and smaller system vendors have a wide 
channel for requirements input and a direct mechanism for influencing the 
definitions and priorities throughout the process. The Shareholders do, of 
course, have a commercial interest, they would not otherwise invest so 
heavily in X/Open and Open Systems; but they expect to get their return 
from growing the market and competing in areas of much greater added 
value (for example industry specialisation and/or systems integration). 

7 Worldwide Requirements Gathering (XTRA) 

During 1988 it was decided to embark on an extensive market requirements 
gathering process to ensure that: 

a) the requirements and priorities were fully understood, 

b) came from a much wider net than that provided on an ongoing basis by 
the Councils, and 

c) were obtained through a planned comprehensive process setting them 
all in proper context. 

This project was called “XTRA”, as it was a very significant extra X/Open 
activity for which the members considered it important to make an extra 
investment. The wisdom of the decision to initiate the XTRA process has 
been amply illustrated, as the results now provide a major input to X/Open 
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strategic and annual planning, and are similarly used by other organisations 
such as Unix International and the Open Software Foundation. 

The first cycle took place in 1989 (XTRA89) and consisted of: 

i) a set of interviews with over 30 organisations in Europe, the USA and 
Japan, 

ii) telephone market research by the Gallup organisation of 430 respondents 
in Europe and the USA (80% users from a broad range of industry 
sectors, 10% ISV’s and 10% system vendors), and 

iii) a three day requirements conference/workshop in Montreal, Canada, 
which brought together 104 senior representatives of user organisations, 
ISV’s, government agencies and non-X/Open system vendors. 

The results were integrated and analysed, and published to the world at 
large in a 224 page book called “The Open Systems Directive” - sub-title 
“Shaping the Future of Open Systems” (ISBN:1 872630 00 6). 

Much was learnt from this first round, and it was decided to repeat the 
conference with a modified perspective in 1990 to validate and further fill 
out the findings, and thereafter to iterate on a two year cycle. At the time 
of writing the XTRA90 conference has taken place and the results are being 
analysed. They will be published later in the year. 

8 Full Open Systems 

The initial focus of X/Open was application portability, and this was consid¬ 
ered to be complementary to ISO Open Systems Interconnection/Inter¬ 
working (OSI), to which several other organisations were contributing. 
However it became clear when X/Open got into the areas of interfaces for 
interconnection, interworking and distributed systems that it was no longer 
sensible to be confined to application interfaces alone. It all needed pulling 
together; there was a need to consider more than just OSI because of the 
systems integration requirements to connect to existing major environments 
(PC’s and Mainframes, Internet and SNA) and there were many more 
aspects needing attention such as user interface (user portability), data 
interchange (data portability), systems management, security and Interna¬ 
tionalisation. It also became clear that the IT industry was wanting X/Open 
to be concerned with Open Systems in general. 

The X/Open mission was therefore widened to be: 

“To bring greater value to users of Information Technology through the 
practical application of Open Systems”. 

X/Open is therefore about a total Open Systems architecture and set of 
standards, and the promotion of the adoption of Open Systems by users, 
ISV’s and the IT industry at large. 
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9 Relationship to Standards bodies, other consortia and owners of de facto 
technology 

The X/Open process involves assessing user requirements and priorities, and 
assembling an architecture and set of standards that will ensure that open 
systems can be provided that will meet these requirements. The best and 
most reliable source of standards is the International Standards Organisation 
(ISO), as these standards have firm international agreement and recognition, 
and are the most stable. If ISO standards existed, and were complete, in all 
the required areas then there would be no need to look elsewhere, and the 
process would be relatively simple. The total picture, however, covers aspects 
ranging from areas where the technology is very mature and ISO standards 
have long existed, right through to areas of recent innovation where no 
standards yet exist. It is therefore necessary to acquire “standards” from 
many other sources. 

The other sources include the feeder bodies to ISO (eg. the national standards 
organisations, like ANSI), and those well recognised for standards develop¬ 
ment, such as IEEE and ECMA. If no standard is imminent from these 
formal bodies then a de facto standard is likely to form the basis of the 
X/Open definition (probably after tightening up and/or subsetting). Finally 
if nothing exists then X/Open may do work towards encouraging the produc¬ 
tion of a “standard”. 

Even long established standards from bodies such as ISO and ANSI may 
not be complete for today’s requirements, or may have several optional or 
implementor defined aspects, so X/Open attempts to fill the gaps and select 
the options. For example the COBOL 1985 standard does not include 
facilities for communicating with the on-line user at a terminal or work¬ 
station, but most of todays applications work in this interactive mode. This 
leaves a big portability hole if all systems provide different mechanisms to 
satisfy this requirement, so X/Open adds to the standard to fill the gap. 

In specific topic areas, other consortia may exist, or be created, with intent 
to define interfaces and/or protocols, and could potentially come into conflict 
with X/Open, and cause a fragmentation in open systems development. 
However X/Open is about uniting the many players in open systems, and 
also its own resources are limited. The policy therefore is to work with such 
other groupings to encourage the work to fit into the X/Open concepts, to 
leverage the output, and to provide the other body with a ready made 
publication channel. During the last two years collaborations have been 
established with the SQL Access Group, the X.400 API Association and the 
Object Management Group. 

Where X/Open adopts a de facto standard, a condition is that the owner 
of the technology makes an agreement that the interface as published by 
X/Open is generally available such that competing products can be produced 
that satisfy the interface. Arrangements are also made that future updates 


ICL Technical Journal May 1991 


573 


will be made available to X/Open, without any commitment that they must 
be incorporated, and that X/Open can separately enhance the interface. 
These conditions make it an open definition (ie. free from single vendor 
control). 

Sometimes X/Open is referred to in articles as “another body working on 
standards”, for example in an article discussing the IEEE POSIX work. 
This can give the mistaken impression that there is a competition and 
fragmentation in Open Systems standards. X/Open is not setting out to be 
in competition with other groups; on the contrary it is attempting to pull 
all together, to fill the gaps, to speed up the process and to encourage 
progress towards full International Standards. 

10 The Open Software Foundation and Unix International 

The Open Software Foundation (OSF) was formed in May 1988, sponsored 
by several major companies including IBM, Digital and HP, with the object¬ 
ive of providing an alternative source of the basic operating system techno¬ 
logy to that provided by AT&T with the UNIX Operating System. Many 
companies became members of OSF, but many others, including ICL, came 
together to form UNIX International (UI) to promote and support the 
continued development of UNIX by the UNIX Software Operation (USO) 
of AT&T. Much has been written on this industry split, and the attempts 
at reconciliation, and it is not proposed to discuss it again here, but only 
to address the implications for, and effect on, X/Open. 

OSF, and UI/USO, represented two major competing sources of base operat¬ 
ing system technology, each with a very large backing of companies that 
would build the technology into their own products, which would then be 
sold in volume. The competition so created was potentially good in that it 
would tend to speed up progress and drive down prices. On the other hand 
the large volume of products deriving from each of the two sources was 
likely to lead to the emergence of equally viable alternative de facto stand¬ 
ards. It therefore provided a big potential for a major split in the open 
systems movement, and a threat to the objectives of X/Open. 

The membership of X/Open, being equally divided between the two camps, 
was faced with a dilemma. Individually each member had an allegiance to 
one of the competing parties, but at the same time was dedicated to X/Open 
and the need for a single set of standards. It was therefore important to 
attempt to ensure that divergences were kept to a minimum and confined 
to areas of significant added value, that both parties were knowledgable of 
and in tune with what X/Open was attempting to do, and that this was all 
in line with what the customers (users and ISV’s) really wanted. It was also 
realised that, although this was a particularly acute case, many of the issues 
would also be present when any two (or more) competing technology 
suppliers were involved (eg. database vendors). 
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X/Open, and the XTRA requirements gathering process (see section 7), did 
however have the potential of playing a key role in ensuring that user 
requirements for open systems standards were really known and understood. 
With X/Open, OSF and UI/USO all working to a common requirements 
base it would be possible for all parties to work co-operatively during 
development of their respective new technologies and the potential new 
interface standards associated with them. 

In the event the results from the XTRA process were adopted by both 
organisations, and big steps forward have been made with respect to the 
standards development phase in that both OSF and UI have made a strong 
commitment to conformance to X/Open standards. They have demonstrated 
this in practice, and both have become full X/Open shareholders and are 
involved in the various committees and working groups. However difficulties 
do occur where the parties have made significant investments in differing 
competing technologies covering the same user requirement, as for example 
is the case for the Graphical User Interface. Consensus agreement in these 
circumstances is not easy. 

[Note that AT&T USO has recently changed its name to UNIX System 
Laboratories, Inc. (USL).] 

11 Branding and Verification 

One of the characteristics of the Open Systems world is the large number 
of consortia to which a particular supplier can belong, and the many 
standards to which different types of conformance can be claimed, all of 
which are used in publicity material regarding the sale of products. This is 
all very confusing to the would be purchaser, partly because there are so 
many of them, and partly because in practice the memberships and conform¬ 
ance statements have very different actual values although often presented 
as though equivalent. For example some are associated with very thorough 
independent conformance testing of products, and thus are of high value, 
whereas others just mean the subscription to the consortium has been paid, 
or that conformance is to a general model not to detailed standards. 

It was decided therefore to make X/Open the umbrella organisation covering 
all aspects of open systems, and that there should be an extremely high 
value conformance claim mechanism, giving purchasers of X/Open systems 
a high confidence level in the quality of the implementation of the standards. 

As described earlier, development of a comprehensive verification suite was 
started during the first three years, and it has continued to be enhanced to 
match the evolving Portability Guide. The suite covers the basic operating 
system, the C language, and many areas (egs. ISAM, XTI) not covered by 
an already recognised formal test suites. Where there are already well 
established formal tests, for example the NIST tests for high level language 
compilers, X/Open incorporates them into its verification procedures. 
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Tests alone are not satisfactory without some way of ensuring that they 
really have been applied to a product, under controlled and repeatable 
conditions; and, as no test is ever fully complete, there must be a mechanism 
to ensure that faults discovered in the field are corrected in a timely fashion. 
An X/Open “Branding” system was therefore introduced which allows a 
special form of the X/Open trademark to be associated with products that 
meet these stringent conditions. To use this trademark in conjunction with 
a product, the supplier must sign a Trademark Licence Agreement (TLA), 
renewed annually, through which it is warranted that the product meets the 
X/Open definition, the specified verification tests have been run by an 
authorised test centre, and that faults subsequently discovered will be cor¬ 
rected. If the licensee subsequently fails to meet the requirements of the 
licence then the right to use the trademark is withdrawn. 

The branding scheme was first introduced in association with XPG2, and 
the conditions significantly tightened for the XPG3 version, which was 
launched in June 1990. There are two principle types of branding, “Com¬ 
ponent” and “Profile”. Each functional component identified in the Portabil¬ 
ity Guide can be separately branded and marketed as an X/Open “branded 
component”. Examples of functional components are Systems Interfaces, 
Commands, COBOL, and SQL. Defined sets of branded components can 
then be further collectively branded as a profile. For XPG3, two profiles 
have been defined, “Base” and “Plus”. To obtain Base branding a system 
must have the Systems Interfaces, the Commands and the C language 
branded as components. For Plus branding the majority of the XPG3 
components must have been branded. All branding is with reference to a 
particular hardware environment; the same software component in a differ¬ 
ent hardware environment has to be separately verified and branded. 

To date branding has been related entirely to application portability, but it 
is now necessary to address the branding implications of interconnection 
and interworking. Although branding is a simple concept, the practical 
details necessary to ensure the integrity of the trademark as an assurance 
of quality in all situations are complex. The added dimension of interworking 
systems is going to need careful attention. 

It is ICL policy to obtain X/Open branding for all relevent strategic products. 

12 Product Management 

A major facet of the X/Open concept is Product Management which ensures 
that all X/Open systems are at well defined levels, and progress forward in 
step. It has been implied in the above sections, but it is important to 
recognise it explicitly. 

X/Open definitions are based on a collection of standards (de jure and de 
facto) which individually are produced by many different organisations with 
no co-ordination between them. For example the issue of the definition (or 
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update) of a high level language standard from ISO, or ANSI, bears no 
timing relationship with that for SQL or POSIX. If X/Open just referred to 
a list of standards that was implicitly updated immediately one of the 
components changed, then the situation for a procurer would be confusing 
as each supplier would have to be queried about the level of each component 
in a particular system. Instead, each XPG level refers to a fixed situation 
with respect to all the components, thus guaranteeing the same definition 
of facilities on any XPGn system independent of the supplier. Similarly 
there is a well defined increment in moving forward to the next product 
level (eg. from XPG3 to XPG4). 

The verification suite increments in these same well defined steps, as it 
supports the branding quality mark at a particular XPG level. This all 
means that an XPG level number (eg. XPG3) can be considered to identify 
a particular X/Open product, which consists of that issue of the Portability 
Guide together with the corresponding version of the Verification Suite, 
Branding Procedures and all associated supporting documentation. 


Another facet of Product Management is that X/Open will attempt to make 
the various components of a particular level consistent with one another to 
aid systems integration. For example if the base is changed to be POSIX 
conformant, as it was in XPG3, attempts will be made to ensure other 
components match this. 

Over the last year it has been decided to make explicit the difference between 
release of the definitions for use by product development teams, and the 
time when they can be used as a Procurement Standard. Up to the release 
of XPG3 there was no distinction; the Portability Guide was issued although 
there could not at that time be conformant systems, and sometime later it 
was assumed that users would procure against it. The June 1990 launch of 
the XPG3 Branding Scheme, and the announcement of several actual 
branded system and components, marked the point at which procurement 
is appropriate, and it is expected that most, if not all, procurements will 
now specify XPG3. In future (beyond XPG3) the release of “Developers 
Specifications”, which will occur as soon as they are ready, will be separate 
from the launch of an XPGn. The product launch will group together a 
number of Developers Specifications into the release, launch the associated 
verification and branding process, and call for procurements at that level 
with immediate effect. 


It has been decided to have two categories of specifications for development 
purposes - full “Developers Specifications” and “Preliminary Specifica¬ 
tions”. The latter are for situations for which there is as yet no working 
code that has proven the interface to be sound in practice; they will not 
form part of a branding release until they have been upgraded to full 
Developers Specifications. 
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13 Major Procurement Policies 

The X/Open concept has from the outset received staunch support from 
government procurement agencies, in particular in Europe, and indeed they 
have been very prominent participants in the User Council. Governments 
have a need to procure from multiple sources, but do not wish to suffer the 
severe incompatibility problems arising from the use of proprietary systems. 
However their regulations often made it difficult to refer to a set of standards 
produced by a group of vendors, and which also included de facto standards, 
instead of just referring directly to the de jure standards that existed. This 
is now changing and strong statements regarding use of X/Open in procure¬ 
ment have been published in many areas (particularly Europe, including the 
UK). 

Actual major procurements statements calling for X/Open (XPG3) have 
been made by specific large government ministries in Germany, Italy and 
Spain, and by several large Fortune 200 commercial organisations both in 
the US and in Europe. 

14 The next Product - “XPG4” 

A great deal of technical standards work has now taken place towards the 
next Product. At procurement and branding release this product will be 
collectively known as XPG4, but, as described in the previous section, the 
individual Development Specifications will be released when they are ready, 
to allow product planning and development to commence. The first batch 
is just being released (August 1990). The following is an indication of the 
scope of the activity and the likely additional components and enhance¬ 
ments. As will be apparent a major thrust is in the area of interconnection 
and interworking. 

Operating System Interfaces and Commands: 

A large amount of effort has gone into alignment with POSIX work on 
Commands (PI003.2 and /.2a), and the updates and enhancements of the 
System Interfaces (P1003.1a, /.lb and /.4). 

Internationalisation activity has been concentrating on the support of 
Eastern Languages and cultural differences, and of multi-byte codesets in 
general. 

The security group has been working on an auditing interface. 
Languages: 

The C Language definition is being aligned with the ISO (ANSI) 
definition. 
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The COBOL group have been working on Internationalisation, both 
single and multi-byte codeset support, and it is likely that at least the 
former will soon be published. 

Data Management: 

Dynamic embedded SQL has been added, and Distributed SQL is being 
tackled in collaboration with the SQL Access Group. 

Window Management/Human Computer Interface: 

Work on the X-Windows Xt_Intrinsics, the X_Protocol and Inter- 

Client Communication Protocol (ICCM) has been completed, and the 
XLIB interface has been brought up to the X-Windows Release 4 level. 

There has been much activity on the toolkit level, both API and Look 
and Feel, but a concensus definition has not yet been achieved. 

PC Interconnection: 

Specifications for connecting an X/Open System as a server to a PC 
network using SMB protocols, and for connecting PC’s into an NFS 
system have been developed. 

Mainframe Interconnection: 

A specification of an interface, based on the IBM CPI-C definition, for 
connection to IBM, and IBM compatible, mainframes has been produced. 

Networking: 

Byte Stream File Transfer based on ISO/OSI FTAM. 

An Application Program Interface to X.400 mail based on collaborative 
work with the X.400 API Association (X.400 APIA taking lead role). 

An Application Program Interface to an X.500 Directory Service based 
on collaborative work with the X.400 APIA (X/Open taking lead role). 

Transaction Processing: 

X/Open published a “White Paper” on a proposed TP model towards the 
end of 1987; and a further Snapshot in 1989 which significantly enhanced 
the model as a result of comments received and much additional work. 
This model provides for components from different software vendors to 
come together on a network of computer systems such that they form a 
single co-ordinated distributed transaction processing system. Since then 
work has gone into developing the detailed interfaces necessary for making 
it a reality. Particular cases are (a) the interface between the Resource 
Managers that have to be co-ordinated (eg databases) and the Transaction 
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Manager(s) that has to co-ordinate commitment and recovery, and (b) 
the interface between the application and the Transaction Manager. 

As stated earlier this is not a complete list. Very significant work is going 
on in other areas such as Data Interchange, including ODA, and Systems 
Management, and some of this may reach fruition in the timeframe of the 
next XPG Product. 

15 The Future 

Predicting the future in this fast moving open systems area is not easy, as 
there are many players and influences, and a rapidly changing technology 
base. Many of the changes that have taken place over the last three years, 
could not have been predicted, in particular the formation of the two major 
competing base technology organisations OSF and UI/USL. What is certain 
is that the big growth in open systems will continue, and will accelerate. 
User demand is increasing rapidly, and is now even starting to grow in the 
mainframe area. 

A big issue will be the tension between standardisation, the foundation of 
Open Systems, and innovation and added value, which are essential for 
healthy competition and technological progress. This represents a significant 
challenge for X/Open as it is important that differences really are confined 
to innovation that delivers high value to users, rather than being in areas 
of low value that ought to be standardised. Also today’s area of innovation 
is tomorrow’s for standardisation. 

The rapid growth in X/Open membership is now probably at an end, as 
most of the major System Vendors are already participating. Additional 
Associate Members and Groups can be anticipated, but this seems likely to 
be counterbalanced by mergers and acquisitions within the existing mem¬ 
bership. 

There will now be an explosive growth in the number of conformant 
X/Open systems in the market. UNIX System V.4, which forms the basis 
of the open system products from a large percentage of the system vendors, 
is XPG3 conformant; and OSF/1 is committed to follow suit. About half 
of the X/Open members have already branded systems at XPG3 level, 
including ICL with UNIX System V.4, IBM with AIX and Digital with 
Ultrix, and most of the rest have committed to do so by the end of the year. 
The resulting high volume of XPG3 systems will further encourage the ISV’s 
to produce conformant applications and users to increase the demand for 
X/Open systems in procurement specifications. The virtuous circle created 
by this positive feedback will really be underway. 

For conformance and branding, the increasing size and scope of the Com¬ 
mon Application Environment is such that the simple breakdown into Base, 
Component and Plus is no longer tenable, so consideration is being given 
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to profiles more related to usage, or possibly even to specific industry. The 
big move into aspects of open systems other than application portability, in 
particular interworking, adds a further dimension which has to be taken 
into account in these profile and branding deliberations. 

With respect to increasing the coverage of the X/Open environment, the 
XTRA User requirements gathering process has put high priority on the 
Human Computer Interface, Interworking (including heterogeneous sys¬ 
tems) and Systems Management, so there will be a high focus on these 
aspects. There will also be completion of the Transaction Processing work, 
and all these topics call for data interchange standards. 

16 Conclusion 

In 1987 an extremely healthy outlook for X/Open was predicted. This was 
borne out in practice over the following three years with the: 

• recruitment of most of the major IT companies, 

• extension of membership to three continents, 

• formation of the X/Open Company Limited 

• creation of the Associate Membership Groups, 

• XTRA requirements gathering process, 

• membership of OSF and UI 

• publication of XPG3, 

• comprehensive branding programme, 

• major commercial and government procurement requirements, and 

• the large volume of work towards “XPG4”. 

XPG3 systems are now being marketed by many companies. This will soon 
lead to a high field population, and a positive feedback effect through greater 
availability of applications and increased user demand. 

The rapid growth in X/Open shareholder membership has stopped, as most 
of the large system vendors are already on board, but a significant growth 
in Associate Membership, and the formation of additional AMG’s, can be 
expected. 

An uncertainty is the degree to which fragmentation can be avoided, as 
more and more work is in areas that are perceived as having added-value 
potential. The problems of many interacting standards bodies and consortia, 
and the more complex technical issues now being tackled all significantly 
increase the X/Open challenge. 

There is now much user pressure for open solutions across the full range of 
system types; and the more they are delivered, the more this will increase. 
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Users will not be satisfied until Open Systems do everything that proprietary 
systems do today (and more). 

There is a great deal for X/Open to tackle over the next three years. 

Trademarks 

UNIX is a trademark of AT&T in the USA and other countries. 

X/Open is a trademark of the X/Open Company Ltd. 

AIX is a trademark of IBM. 

ULTRIX is a trademark of Digital Equipment Corporation. 

OSF/1 is a trademark of the Open Software Foundation. 

The X Windows System is a trademark of M.I.T. 
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Appendix A 

This appendix lists the members of the X/Open User Council as at end August 1990: 

User Council Chairman: 

Walter de Backer, Director of Informatics, Commission of European Communities. 

User Council Members: 

Amoco Corporation (US) 

Arco Oil & Gas Company (US) 

Automobile Association (UK) 

Bellcore (US) 

Boeing (US) 

British Telecom (UK) 

Central Computer & Telecommunications Agency (CCTA) (UK) 

Commission of the European Communities (CEC) (Europe) 

Daimler-Benz AG (West Germany) 

DHL International (US) 

DuPont (US) 

Eastman-Kodak Co. (US) 

Elf Aquitaine (France) 

Ericsson (Sweden) 

Exxon Production Research (US) 

Ford Motor Company (US) 

Gerling Konzern (West Germany) 

Harris Corporation (US) 

Landesamt fur Datenverabeitung und Statistik (West Germany) 

McDonnell-Douglas Corporation (US) 

National Institute of Standards and Technology (NIST) (US) 

Shell International Petroleum (The Netherlands) 

Statskontoret (Sweden) 

Swedish Post (Sweden) 

Swedish Telecom (Sweden) 

Telefonica (Spain) 
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Union Bank of Switzerland (Switzerland) 
US Department of Agriculture (US) 

US Treasury 


Appendix B 

This appendix lists the members of the ISV Council as at end August 1990: 


ISV Council Chairman: 

Roger Sippl, Chairman, Informix Software. 


ISV Council members: 

ASCII Corporation (Japan) 

Informix Software (US) 

Ingres Corporation (US) 

Interactive Systems Corporation (US) 
Liant Software Corporation (US) 
Micro Focus (UK) 

Microsoft Corporation (US) 

Netwise International (US) 

Novell Inc. (US) 

Oracle Corporation (US) 

Progress Software (US) 

Quadratron (US) 

Retix Corporation (US) 

Santa Cruz Operation (US) 

Softlab Gmbh (West Germany) 
Sybase (US) 

Tecsiel- IRI Finsiel (Italy) 

Tietotehdas Group (Finland) 

Unify Corporation (US) 

Uniplex inc. (UK) 
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Abstract 

Research on database machines has been very active at all times 
since the 70s: however, only a small number of machines have been 
converted to commercial products from their research prototypes. In 
this paper, the architectures of a number of commercial and research 
database machines are described. Due to the rate of advance in 
software and hardware technologies, some people believe that data¬ 
base machines are not cost effective. This belief is disputed: from 
the success of some commercial database machines, it is argued 
that a database machine is useful, especially to high-end database 
users who work on very large databases containing over giga-bytes 
of information. Furthermore, from the study on commercial machines, 
factors influencing the acceptance of a database machine are identi¬ 
fied. Architectures of research database machines are also import¬ 
ant. They can influence the design of future machines. From the 
review on research prototypes, the trends in database machine 
architecture are outlined. 


1 Introduction 

The increasing complexity of Data Base Management Systems (DBMSs) 
and the growing size of modern database applications render conventional 
von-Neumann processors inefficient for supporting them. This inefficiency 
is mainly caused by a technology mismatch between the DBMS software 
and the underlying hardware: 


• Computational gap. Von-Neumann computers were designed primarily 
for numerical processing. They are inefficient in performing non-numer- 
ical operations such as database join, select, project, update, etc. This 
predicament gets worse as the database size increases. Also, conventional 
processors support various address modes e.g. index, direct, etc. Al¬ 
though, these addressing modes are efficient for referencing arrays and 
simple data structures, they are unsuitable for accessing database re¬ 
cords. The latter are frequently addressed by content i.e. a specific set 
of attributes. 
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• Semantic gap. One of the advantages of DBMS is the notion of data 
transparency. Under this notion, database users are unaware of the 
physical storage mechanisms of the database. This may require the 
maintenance of several auxiliary files e.g. secondary index files, inverted 
index files, etc. The user view of a database is very simple - a database 
appears as a set of well defined data records, e.g. tuples in the relational 
model. The mapping from a user’s logical view to its physical representa¬ 
tion generally involves a series of address translations. This mapping is 
time consuming and is not efficiently supported by the underlying von 
Neumann processor. 

• IjO and buffering bottlenecks. A database is usually kept in centralised 
secondary storage, discs, shared by a number of users. Database opera¬ 
tions are not executed directly at the secondary store. Parts of a database 
are read from the secondary store and buffered in some intermediate 
stage memory. The DBMS then operates on the buffered data. The 
limited size of the stage memory forces paging to take place frequently 
when dealing with large databases - buffering bottleneck. Common 
operating system techniques for maintaining program/data locality dur¬ 
ing buffering are not suitable for database applications. Moreover, the 
load on the secondary storage device increases linearly with the number 
of users. The rate at which data can be transferred from the secondary 
storage device is very limited. It is generally much slower than the data 
request rate of the DBMS. This limitation is referred to as the IjO 
Bottleneck and can seriously affect database performance. 

To improve DBMS performance, many special purpose database machines 
have been proposed [28]. These database machines are designed to overcome 
the problem of technology mismatch. The design of a database machine 
involves migrating the DBMS functions from the host to the machine in an 
effective way (see fig. 1). In doing so, the load on the host is reduced and 
the DBMS functions can be more efficiently executed on the specialised 
database machine; hence, the computational and semantic gaps are nar¬ 
rowed. In practice, the extent to which the load of a DBMS is shared varies 
between different database machines. In a basic database operation, a con¬ 
ventional DBMS accepts a user query, parses it, decomposes and converts 
it into a database operation tree, accesses the data files on the secondary 
storage devices and performs the required operations. In an ideal database 
machine environment, the host handles the user interface, accepting queries 


DBMS 

1 

Database 

2 

Secondary 


HOST 


Machine 


Store 



1 Move DBMS functions to Database Machine 

2 Move the logics of Database Machine closer to the Secondary Store. 


Fig. 1 Principles of database machine design 
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and handling results, and the database machine caters for the processing of 
the query. Another principle in database machine design is to move the 
logic of the database machine physically close to the secondary storage 
device. This action can be regarded as moving DBMS functions to the data 
rather than moving data to the functions as in a pure software DBMS 
environment. This reduces the amount of data returned to the host and 
effectively, minimises the I/O and buffering bottlenecks. According to how 
they are integrated into a computer system, database machines can be 
classified as:- 

• Filters. These are devices which are attached between secondary and 
main memory and function at the operation level - they accept and 
execute database operations, e.g. select, issued by the host. Generally, 
filters are ‘slave’ devices; they are programmed by the host before an 
operation is initiated. They perform the required operations on the data 
as data streams from the secondary storage devices to main memory. 
In order to achieve real time (or ‘on-the-fly’) performance, only simple 
database operations are supported. An example of a database filter is 
ICL CAPS. 

• Database Accelerators. These are coprocessors which are tightly integ¬ 
rated with the host. They are specially designed to expedite database 
operations. Similarly to database filters, database accelerators function 
at the operation level and are ‘slave’ devices. The difference between the 
two lies on the location of data processing: filters process the data while 
it is being transferred from the disc and accelerators assume the data 
to be in main memory. An example of a database accelerator is Hitachi 
IDP. 

• Backend Database Machines. These are dedicated machines which func¬ 
tion at query level - they accept and execute a database operation tree 
which is generated by the host upon receiving a user query. These 
machines achieve intra-query parallelism by executing the database op¬ 
erations in parallel. Examples of backend database machines are the 
Teradata DBC/1012 and the Gamma database machine of the Univer¬ 
sity of Wisconsin. 

• Dedicated Database Computers. These are standalone computers with a 
full DBMS capability and function at the transaction level - they accept 
and execute database transactions (a series of queries). These machines 
are the most complex and achieve inter-query parallelism. Examples of 
standalone database computers are ICOT’s Delta, Grace of the Univer¬ 
sity of Tokyo and Bubba of MCC (USA). 

This paper looks at the architecture of several ‘now’ and ‘emerging’ machines 
[15]. ‘Now’ machines are existing commercial machines; they are studied 
because of their importance to the current database community. ‘Emerging’ 
machines are forthcoming machines existing as prototypes in research 
laboratories; they are studied because the philosophy behind their designs 
will influence the architecture of future database machines. The main inten¬ 
tion of studying the various ‘now’ and ‘emerging’ database machines is to 
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find out the trends in database machine architecture and to identify factors 
which need to be taken into account when designing a practical database 
computer. 

The paper is structured as follows: the architectures of a number of successful 
commercial machines are described in section two. The states of these 
machines are reported and the factors which will affect the acceptance of a 
database machine are identified in section three. Section four reviews some 
research projects on database machines. From the architecture of the re¬ 
search and commercial database machines, trends in database machine 
architecture are outlined in section five. Section six - Conclusions - is a 
summary of the paper. 

2 'Now’ Machines 

2 1 ICL CAPS 

CAPS is a filter-oriented database machine developed by ICL (UK) [4, 13, 
18, 19]. It is an optional processing unit which attaches to an ICL disc 
system (e.g. FDS300) in a ‘piggy-back’ fashion. The CAPS system is used 
in both formatted and unformatted applications on ICL 29 or 39 series 
mainframes. The architecture of the basic CAPS is depicted in fig. 2. CAPS 
consists of the following functional parts: 

1 The Data Multiplexing Unit (DMU) is a programmable switch. De¬ 
pending on the setting of the switch, disc resident data may either stream 
to the host directly or be processed by the CAPS search engine before 
reaching the host. 

2 The CAPS search engine is the heart of CAPS. It compares disc resident 
data with some pre-programmed values. Internally, it consists of the 
following sub-units: 

• Logical Format Unit (LFU). This unit generates the timing control 
signals which mark the separate fields in a record (or relational tuple). 
These signals are used to control the operating sequence of the other 
units. 

• Key Channel (KC). The Key Channel is divided into 16 functional 
blocks. Each block consists of a 256 byte RAM and a comparator. 
The RAM contains a specific field which is compared with the input 
data at the comparator. The comparator compares the content of 
the RAM with the incoming data a byte at a time; it tests if the two 
are equal ( = ), less than (<) and/or greater than (>). Using the 
comparator, other tests can be achieved, i.e. the positive (e.g. >) and 
negative (e.g. ^) combinations of the three basic comparisons. The 
output from the Key Channel is a 16 bit word derived from the 
results of the 16 comparators. 

• Search Evaluation Unit (SEU) . The function of the Search Evaluation 
Unit is to monitor the 16-bit word from the Key Channel and test 
if it contains the desired bit pattern. The result is another 16-bit 
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Fig. 2 The architecture of the ICL CAPS 


word. If the first bit (bo) of the output word is set, the corresponding 
record is a hit. 

• Retrieval Unit (RU). Driven by the LFU, the RU informs the Re¬ 
trieval Processor (RP) which fields of a record should be retained. It 
also monitors the result of the SEU and informs the RP to overwrite 
the current entry of the retrieval buffer if the result of the comparison 
is negative. 

3 While a record is being compared, a copy of it is buffered in the Retrieval 
Processor (RP). This buffer location is overwritten if the test bit from 
the Retrieval Unit is negative; otherwise the record is stored. Also, the 
Retrieval Processor is programmable to perform aggregate functions at 
the end searching a block of data. 

During a CAPS session, a user query is translated into a CAPS Control 
Block. A control block contains the parameter settings and the microprog¬ 
rams of the various internal units. 
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The design of CAPS started in the mid 70s. Through the years, many 
additional features have been introduced. The implementation of hashed 
join using a set of hash coding hardware and a set of bit arrays was 
introduced by Babb [3, 4]. Babb’s bit array expedites join operations which 
are performed by the Retrieval Unit in the basic CAPS. 

A novel hashed join algorithm is achieved using the Babb bit array. During 
a join operation, the source relation is initially read. The join attributes of 
every tuple are hashed and are used as addresses to the bit array. If a bit is 
addressed, it is automatically set. After the source relations are completely 
read, the target relation is read. The join attributes of every target tuple are 
hashed as before and used as addresses to the bit array. If an addressed bit 
is set, the target tuple is retained. CAPS only supports implicit (semi-) join - 
the result of the join is contributed by the target relation alone (on the other 
hand, in natural join, both source and target relations form the result 
relation). In general, the complexity of hashed join is proportional to the 
sum of the size of the source, target and result relations (i.e. Join Complex¬ 
ity = 0(Cs -h Cl -f Cr)), where C with subscripts s, t and r correspond to the 
cardinalities of the source, target and result relations.) In CAPS, the result 
tuple is pre-stored at the Retrieval Unit, therefore the complexity is reduced 
to 0(Cs-}-Ct). 

The bit array is also used for projection. During the operation, the source 
relation is read through CAPS. The projection attribute of a tuple is hashed 
and used to address the bit array as in the join operation. The corresponding 
bit position is set if it has not been done; otherwise, if the bit is already set, 
that means this record is a duplicate and will be discarded. This technique 
is fast and requires only one scan of the source relation. 

Both the join and projection operations are efficient in terms of speed. 
However, because of the non-unique hashed values generated by the hash 
coding hardware, the techniques are error-prone. In the case of joins, ‘false 
drops’ (or ‘ghosts’) are generated at each read. The error propagates into 
target relations; thus the effect amplifies for higher order joins (i.e. m-way 
join). Por projection, the damage is worse and, is some cases, it is unac¬ 
ceptable. The imperfect hashing can lead to loss of data. 

Currently, new development proposals have been suggested for the next 
generation of CAPS. One such proposal is the implementation of a CMOS 
VLSI CAPS. The existing CAPS, which attaches to a PDS300 disc system, 
consists of over 10 PCBs and the power consumption is very high. The 
objectives of the CLSI CAPS are to tackle these problems. Another proposal 
is to interface CAPS to other ICL computers, such as the DRS series 
workstations. (A prototype has been implemented for the DRS300 [6].) 
Most recently, ICL has announced CAPS for its new UNIX machines [1]. 
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Hitachi IDP 


The Integrated Database Processor (IDP) is a SIMD processor designed for 
database applications [17]. It is a commercial product launched in 1986 by 
Hitachi. It is sold as an optional processing unit integrated with the Hitachi 
M680H high performance large scale general purpose computer. The IDP 
is a database accelerator. It is a purely passive device under the control of 
the host processor. Query interpretation is performed by the host and the 
IDP carries out only the execution of the database operation commands set 
up by the host. 

Database operations are executed in pipelines and are based on a technique 
known as dynamic vectorisation. Using this technique, database files on 
discs, which are logically viewed as tables (or row-major format), are dynam¬ 
ically converted to a set of vectors (or column-major format) at run time. 
Vectorisation is not a compulsory operation. When a query is entered to 
the host, it is passed to a query analyser. Depending on the nature of the 
query, the latter decides whether the database should be processed in ‘row¬ 
wise’ or ‘column-wise’ fashion. If ‘row-wise’ processing is selected, the 
database will be processed by the host using a scalar processor. Otherwise, 
column vectors are generated and collectively processed by the IDP. ‘Row¬ 
wise’ processing is advantageous for tuple-based queries where database 
tuples are processed one at a time. On the other hand, for set-based queries 
where sets of tuples are processed under certain attributes, ‘column-wise’ 
processing is more efficient. The query analyser is intelligent enough to work 
out the optimum processing mode. 

The configuration of the IDP/Host system is shown in fig. 3. The Host 
machine is a Hitachi M-680H. The lAP, Integrated Array Processor, is 
another optional processor which is used for conventional vector operations 
(e.g. Vector Element Increment). The IDP utilises the lAP functionality; 
therefore, the existence of the lAP is a prerequisite to the installation of the 
IDP. The host system is responsible for all scalar operations, including query 
analysis and all ‘row-wise’ operations. After query analysis, if the host 
decides that a query is best executed ‘column-wise’, the vector processing 
software will be invoked. This software initiates a data transfer from the 
discs and dynamically vectorises the data and stores it as column vectors in 
the main storage. The operations of both the lAP and the IDP are controlled 
by the microprograms in the control storage on the host. 

Internally, the IDP adopts a pipeline architecture. It consists of a 6-stage 
pipeline; execution in each pipeline stage can be completed within 1 machine 
cycle. The IDP appears as a single board system containing 72 ECL LSI 
components. The IDP hardware is relatively small compared to the M-680H 
hardware - the former is approximately 5% of the size of the latter. The 
IDP supports a proprietary set of instructions. These instructions can be 
used in different database operations as shown in table 1. The execution 
details of these instructions are described in [17]. 
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Fig. 3 The Hitachi IDP/Host configuration 

Table 1 The I DP instructions and their corresponding database opjerations. 


Instructions 

Database operations 

SORT 

set-union, merge-sort 

JOIN 

set-product, merge-join 

DIFFERENCE 

set-difference 

SEARCH 

restriction, selection, aggregation, duplicate removal 


Evaluation of the IDP shows that running a hardware sort using the pro¬ 
cessor is approximately 10 times faster than the fastest software sort pro¬ 
grams based on 0(nlog2n) sort algorithms. Also, comparing joins using the 
IDP and conventional software join based on ‘row-wise’ processing, the 
former is 15 times faster. However, for performing light-weight operations 
such as indexed searching, there is no difference in performance between 
the IDP and software. This is because the vector length (i.e. the index size) 
is too short for the vector processing of the IDP to be effective. 

The idea of dynamic vectorisation is good, providing it can be used effici¬ 
ently. The result shown for the join operation is promising [17] and cannot 
be achieved by any software algorithm running on a conventional sequential 
processor. Also, the IDP hardware speeds up sort and merge which are 
frequent processes in database applications. The machine requires a fair 
amount of working space. In the machine proposed in [17], the M-680H/ 
IDP configuration consists of a 256K byte cache, IM bytes of working space 
and 256M bytes of main storage. This amount of memory is necessary to 
hold the vector tables and intermediate results. 
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2.3 Teradata 080/1012 


The DBC/1012 (Data Base Computer/1012) is a commercial product from 
Teradata Corporation [29]. It is a completely standalone database machine 
which can either be connected to several host systems (e.g. IBM mainframes 
running MVS, UNISYS mainframes running OSllOO, ... etc.) as a back¬ 
end database computer or be configured as a database server connected to 
a number of workstations and PCs via a local area network (LAN). The 
DBC/1012 is designed to support relational database applications in a shared 
information environment. The shared information architecture of the 
DBC/1012 is depicted in fig. 4. 
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TOP 

TOP 


TOP 


TOP 


Fig. 4 The shared information architecture of Teradata DBC/1012 

1 Interface Processor (IFP. The role of the IFPs is to manage the I/O 
communication between mainframe front-ends and the DBC/1012. Each 
IFP is composed of a channel interface controller, a CPU, some memory 
and two Y-net interfaces - DBC/1012 internal bus interface (see later). 
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A minimum of two IFPs are connected to each mainframe for supporting 
‘fail-safe’ - fault-tolerant - operations. 

2 Communication Processor (COP). The role of the COP is to manage the 
I/O communication between the workstations or PCs on a LAN with 
the DBC/1012. Each COP incorporates a LAN interface controller, a 
CPU, some memory and two Y-net interfaces. At least one COP is 
required per network. The COP network interface supports various 
communication protocols, including TCP/IP, ISO/OSI, XNS and SNA. 

3 Access Modules Processor (AMP). The AMPs execute relational data¬ 
base primitives (join, project and select), access the appropriate discs 
and prepare results during a user query. An AMP is connected to up to 
4 Disc Storage Units (DSUs), see later. When database tuples (or records) 
are stored, they are horizontally distributed across all DSUs in the 
system - forming buckets of data. Under this arrangement, each AMP/ 
DSU pair can operate on its associated DSU simultaneously with the 
others. For improved performance, an optional 2M-byte non-volatile 
disc cache can be added to the basic AMP configuration. 

4 Disc Storage Unit (DSU). The DSUs are standard large volume Winch¬ 
ester discs. Each contains buckets of relational database tuples and also 
certain system work files, e.g. spooling information. Optionally, part of 
the DSU can be designated as a critical data region. Data in these regions 
may be intentionally or automatically duplicated in order to prevent 
accidental information losses. 

5 Ynet. The Ynet [30] - a patented design of Teradata Corporation - is 
the heart of the DBC/1012. It is an intelligent interconnection bus which 
connects the IFPs, COPs and AMPs. A Ynet interface node incorporates 
logic to perform hardware sort/select operations on data as they pass 
through. The sort/select capability is used to support relational database 
operations (e.g. sort-merge joins). Two Ynets are connected to each IFP, 
COP and AMP. Each Ynet is fully independent: it has separate circuits 
with separate power supplies. Normally, both Ynets share the load; 
however, if one of them is inoperative, the other will take up the full 
load. 


The processor modules - IFP, COP and AMP - have a similar hardware 
architecture which consists of a CPU, a controller, some memory and two 
Ynet interfaces constructed from four printed circuit boards. The difference 
between the three modules lies in the interface controller. The IFP, COP 
and AMP have respectively a controller for a channel interface, a network 
interface and a disc interface. There are three models of processor module: 
model 1 which is the earliest version (ca. 1983) incorporates a 8086 CPU 
and a 8087 numerical processor unit (NPU); model 2 incorporates a 80286 
CPU and a 80287 NPU; and the latest model 3 incorporates a 80386 CPU 
and a 80387 NPU. (CPUs and NPUs in all three models are Intel processors). 
The three models can be mixed within a DBC/1012 system; thus reducing 
the cost of system upgrade. A DBC/1012 system may be configured with 
from 3 to 1024 processor modules. 


ICL Technical Journal May 1991 


593 


To connect a computer (mainframe or workstation), the computer is required 
to run the proprietary Teradata Directory Program (TDP, see fig. 4). The 
TDP manages the channel activity and services user requests. A user query 
is passed to the TDP on the host and is dispatched to the DBC/1012. The 
IFP receives the query and translates it to relational database worksteps. 
The worksteps are broadcast to the appropriate AMPs via the Ynet. Each 
AMP executes the worksteps with its associated DSUs. The AMPs function 
in parallel. The result is transmitted back to the TFP via the Ynet and 
subsequently returned to the host via the TDP. During their journey to the 
TFP, the Ynet interface node may perform hardware select/sort, thus 
merging the results from all AMPs into one master solution set. 

At the user-interface level, the DBC/SQL query language is needed. A user 
can issue DBC/SQL statements to the DBC/1012 in three ways: interactively 
using the ITEQ (Interactive TEradata Query) facility; as embedded DBC/ 
SQL instructions in application programs; or in batch mode through the 
BTEQ (Batch TEradata Query) facility. 

Select and project operations are straightforward and simply require the 
specific select/project attributes to be hashed and distributed to the appropri¬ 
ate AMP/DSU pairs. Joins can be performed by different algorithms: nested- 
loop, hashed-join and sort-merge algorithms depending on the join attributes. 
For instance, if none of the join attributes of the 2 joining relations is a 
primary index, either the nested-loop or the sort-merge algorithm will be 
used - if the latter algorithm is used, the joining tuples must be sorted. On 
the other hand, if one of the joining attributes is a primary index (unique 
or non-unique), the hashed-join algorithm will be adopted. Moreover, for 
any database operation, ordered results can be achieved by utilising the 
Ynet’s select/sort functionality. 

2.4 ShareBase ServerldOOO 

The Servers /300, /700 and /8000 are back-end database machines developed 
by ShareBase (formerly known as Britton-Lee). The philosophy of the Server 
mechanism is based on the Share database system architecture. Server/8000 
is the most recent product from ShareBase marketed in April 1989 [22]. The 
other machines Server/300 and Server/700 were originally marketed by 
Britton-Lee and were known as Intelligent Database Machines (IDMs). The 
architecture of the I DM 500 (now known as Server/700) is reported in [31]. 

The Shared Database System Architecture is equivalent to the Teradata’s 
Shared Information Architecture. Both architectures are based on the notion 
of a database server containing some centralised information being shared 
by multiple heterogeneous client computers. Different client computers are 
supported, e.g. SUN and Apollo workstations. Fig. 5 shows the Shared 
Database System architecture based on Server/8000. Server/8000 consists of 
the following functional units implemented at board level: 
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Fig. 5 The ShareBase’s Shared Database Architecture based on the Server/8000 
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1 Database Processor. The database processor (RDBP) is the heart of the 
Server/8000 hardware which was specifically designed for fast relational 
operations. It is an ECL RISC with 16 sets of register-windows (each 
window consists of 16 registers). 

2 IjO Processor System. Server/8000 has 2 or more I/O processor systems. 
These processor systems have their own local memory and operate 
independently. Their roles are: to accept queries from the clients, return 
the required answers to the requesting clients and interface to the disc/ 
tape sub-units. Up to 104 disc spindles and 4 tape drives are supported. 
The maximum storage capacity of the Server/8000 is 104 Giga-bytes. 
Each I/O processor system consists of 3 processors: 1 Motorola 68020 
and 2 Intel 8032s. Together they control 2 SCSI interface buses. One of 
the SCSI buses, the ‘D’ interface connects the Server/8000 to up to 7 
disc/tape controllers; the other bus, the ‘S’ interface provides connections 
to the Ethernet and the RS232 controllers. 

3 Maintenance Processor. The Maintenance Processor is designed for unat¬ 
tended operations. Its architecture is based on an Intel 80286 micropro¬ 
cessor. The role of the maintenance processor is to support: 
bootstrapping, console handling, error logging and hardware diagnosis/ 
debugging. 

4 Data!Procedure Memory. The memory of the Server/8000 memory is 
divided into 2 separate sets of memory boards for data and instructions. 
The code for the Server/8000 operating system and database management 
system reside in the procedure memory. The procedure memory consists 
of 2 Mbytes of static RAM. The data memory functions as a shared 
disc cache. Each data memory board consists of 16 Mbytes of dynamic 
RAM plus one word of protection memory for each data page. The size 
of the data memory can be up to 256 Mbytes. 

5 Memory Controller. The memory controller provides access and refresh 
mechanisms for the dynamic RAM in the Data memory. 

6 Translation Lookaside Buffer (TLB). The TLB translates the logical 
address issued by the database processor to a physical memory address 
which is used by the memory controller. Also, it supports several memory 
protection schemes. 


On the software side, the Server/8000 database machine utilises a proprietary 
system - ShareBase II [23]. The ShareBase II software supports a client/ 
server architecture for database sharing. (An earlier version, ShareBase I, 
only runs on the Server /300 and /700). It consists of client software and 
relational management software. The latter resides on the Server/8000. The 
client software runs independently on local sites (clients). It consists of a 
variety of tools and utilities to facilitate system administration and applica¬ 
tion support. The facilities provided by the client software included 


* A summary of the ShareBase II facilities is given in Chapter 2 of [23]. 
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1 Query Facility. This parses query language statements in the form of 
SQL and IDL (Intelligent Query Language, an extension of QUEL from 
Britton-Lee) and sends them to Server/8000 machine. It also receives 
resulting data from the server and displays it in the desired format. 

2 Application Facility. This provides a software environment for developing 
system and application programs. It consists of a run time library 
(IDMLIB for C, Fortran or Cobol programming) and a number of 
precompilers. 

3 Share Tools. This consists of a set of programmer tools developed by 
other vendors (e.g. FREEFORM - a portable, screen based query gener¬ 
ator for non-SQL users, etc.) 

4 Development Administration Tools. These provide a set of system com¬ 
mands (e.g. idmcopy transfers formatted data between a client and 
Server/8000) for administrating databases. 

5 ShareCom. This is the network software which allows ShareBase clients 
to communicate with the server. ShareBase II supports the following 
communication options: RS232 serial communication, Ethernet/XNS, 
Ethernet/TCR and Ethernet/DECnet. 

The ShareBase II software on the Server/8000 (the server software) is a 
relational database management system which also provides backup/restore, 
security and concurrency control facilities. Backup/restore is achieved by 
journalling (logging) together with mirrored disc support. The latter allows 
the Server/8000 to continue to operate in the event of disc failure. Security 
allows users to hide sensitive data. This can be performed at different levels: 
database, table and column. 

3 Current States of the Commercial Machines 

Although research on special purpose database computers for handling large 
information systems has been pursued very actively since the beginning of 
the 70s, only a few machines have been converted to commercial products 
from their laboratory prototypes. Among them, the ICL CAFS, Hitachi 
IDP, Teradata DBC/1012 and ShareBase Server/8000 are the best known 
examples. 

ICL and Hitachi designed CAFS and IDP, respectively, as dedicated proces¬ 
sing units to integrate with their mainframe computers. Therefore, the 
markets of these two database machines are quite narrow; they are mainly 
localised to their respective countries, U.K. and Japan, where ICL and 
Hitachi computers are most widely used. For example, in England ICL 
CAFS are employed in many government offices (such as the Inland Rev¬ 
enue). The other three database computers support open system principles. 
They were designed to integrate with different host platforms, including 
various mainframes, minis and workstations. The growing importance of 
networking (both LAN and WAN) enabling inter-connection of different 
computers forming heterogeneous computer systems favours open system 
database machines. 
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At present, a large portion of the world’s market for database machines is 
occupied by the Teradata DBC/1012 and the ShareBase Server(s). Moreover, 
the ‘open system’ strategy adopted by the machines makes them popular 
with database users who want to upgrade and improve the performance of 
their existing database systems. Approximately 800 Server/300 and 
Server/700 database computers have been installed; and the Teradata 
DBC/1012 has about 100 installations [11]. Together they occupy at least 
80% of the world database computer market. The Server/300 and Server/700 
are targeted at small- and medium-sized database users. They are cheaper 
than the DBC/1012 and handle databases with up to 1 Giga-byte of data. 
On the other hand the DBC/1012 is designed for large database users; it is 
more expensive and caters for databases with capacities up to 1 Terabyte 
(10^^). The Server/8000 introduced in mid 1989 is the ShareBase solution 
to large databases. The database capacity of the machine approaches that 
of the DBC/1012; databases handled by the Server/8000 can contain up to 
104 Gbytes. In the meantime the small- and medium-sized database markets 
of Server/300 and Server/700 are being challenged by many software altern¬ 
atives. These include the systems from Sybase, Informix, Oracle, Sequent, 
Pyramid and Ingres which are cost effective software database engines based 
on a client/server architecture. 


3.1 Factors Affecting Acceptance of a Database Machine 

The level of market acceptance of database systems shows that specialised 
hardware machines are not widely used by database users. It is always 
argued that the cost/effectiveness of a specialised database machine is insigni¬ 
ficant because of the rapid advances in hardware/software technology (e.g. 
the introduction of high performance general purpose processors and soph¬ 
isticated software database engines). In general, a specialised database ma¬ 
chine can only be considered as more effective than software database 
systems if it can offer a one order of magnitude performance improvement 
over the latter. Compared with their host computers, a number of existing 
commercial database machines (including the ones described in this paper) 
do satisfy this performance requirement. 


The argument of advances in hardware/software technology is one-sided. 
The size and complexity of database systems do not remain static; they grow 
along with software and hardware technology. There is a limit to the ability 
of general purpose processors to cope with large complex databases. Com¬ 
mercial database management systems are implemented on top of general 
purpose operating systems. Due to the different operational requirements 
of the two systems [26], this piggyback approach is very inefficient. Its 
performance may be acceptable for small- or medium-sized systems, but it 
is intolerable for large databases. Special purpose database machines (e.g. 
the DBC/1012 and Server/8000) have their own management systems which 
are tailored to utilise the machine resources efficiently. For this reason a 
specialised database machine is suitable for large database applications. 
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Choosing between a hardware database machine and a software database 
engine for a given database system depends heavily on the size of the 
application that the system is designed to handle. Influenced by the advance 
of hardware/software technology, the capacity which software engines can 
handle is steadily increasing. At present, hardware database machines, e.g. 
the Server/8000 and DBC/1012, are designed to deal with very large data¬ 
bases containing over 10^ (giga) bytes of information. Handling databases 
of such a large size can only be efficient with specialised hardware. However, 
in the near future, the capacity of a software engine will also approach the 
giga-byte range. Therefore, database machine designers must provide some 
features to keep up with the progress of the software engines. The strategy 
is to design a database machine with a scalable architecture so that the 
machine can cope with future system expansion. Effectively, scalability 
extends the “life cycle” of a database machine. This feature is highlighted 
in the architectures of the DBC/1012 and Server/8000 database machines. 

Other factors which influence the use of specialised database machines are 
the software and hardware connectivities. “Most changes to existing data¬ 
base systems are evolutionary rather than revolutionary” (chapter 9 of [28]). 
Users would be less reluctant to adopt database machines if the effort in 
porting their existing databases to the machines were simple (software 
connectivity). The success of a database machine will depend on how easily 
it can be integrated into existing systems (hardware connectivity). Since 
systems based on networked heterogeneous computers are becoming widely 
accepted, a database machine must be designed with an ‘open system’ 
interface allowing it to connect to different computer models. 

Reliability is also an important design factor. It can be very costly to abort 
or disrupt a database application when a small part of the database machine 
becomes inoperative. A practical database machine, therefore, must be 
designed to handle this sort of situation reliably. This is achieved by incorp¬ 
orating a redundant subsystem which can be activated and replace the faulty 
parts of the machine when it goes down. Furthermore, reliability in storage 
is also very important. Provision of backup storage facilities (e.g. mirrored 
discs) to prevent accidental loss of information is crucial. 

Summarising, due to the increasing size and complexity of database systems, 
there is undoubtedly a need for specialised database machines. However, 
because of the challenge from their software counterparts, hardware data¬ 
base machines are only used in large database systems. They are targeted 
only at high end users for cost/performance reasons. To achieve widespread 
acceptance in the database community, the following factors must be care¬ 
fully considered when designing a database machine: 

• Software connectivity - how easy is it to port an existing database 
system to the database machine? 

• Hardware connectivity - how easy is it to connect the database machine 
to existing hardware? 
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• Scalability - how easy can the database machine cope with future 
expansion, in both size and complexity? 

• Reliability - how tolerant is the machine to faults and errors? 

4 ‘Emerging’ Machines 

4.1 Grace 

The Grace machine [10, 16] is a relational database computer for the 
Japanese Fifth Generation Computer System (FGCS) produced by the 
University of Tokyo. The target of the FGCS research programme is to 
develop a complete (hardware, firmware and software) knowledge informa¬ 
tion processing environment [20]. The overall architecture of the FGCS 
consists of a network of standalone personal inference machines (such as 
the Personal Sequential Inference Machine, PSI, or the Parallel Inference 
Machine, PIM), knowledge base machines (KBM) and relational database 
machines (RDBM). Grace is one of the RDBM candidates. 

Join is the most time consuming and complex database primitive. By 
speeding up the join operation, the overall performance of a database system 
can be enhanced. The Grace machine was designed based on this philosophy. 
The architecture of the Grace machine, shown in fig. 6, consists of 4 different 
types of functional modules connected together by two ring networks, the 
processing and the staging rings: 

1 The P-module (Processing module) is responsible for the execution of 
database operations. Internally, it consists of a custom VLSI sorter (SO), 
a tuple manipulation unit (TMU), a hash unit (HU) and an interface 
unit (lU) connected in tandem; these units are controlled by a control 
unit (CU). The SO, TMU, HU and lU are connected in tandem and 
operate in a pipeline fashion. The dedicated VLSI SO supports real time 
linear sorting at the disc transfer rate. 

2 The M-module (Memory module) consists of some memory used as a 
working space for holding tuples of the relations involved in an opera¬ 
tion. Such tuples may be derived from permanent base relations on the 
Disk modules; or they may be intermediate results in a complex query 
derived from the P modules. 

3 The D-module (Disc module) consists of discs for permanent storage of 
relations. A Filtering Unit (FU) is attached to the discs for selective 
retrieval of disc resident tuples. A Hashing Unit (HU) connected to the 
output of the FU, applies hardware hashing to the selected tuples. The 
selected tuples are deposited in the appropriate M modules according to 
the hash values. 

4 The C-module (Control module) coordinates the other 3 modules so that 
the overall system works efficiently. 

During query processing, a query is decomposed into a number of database 
operations. The execution of the database operations is grouped into tasks. 
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P-Module 



D-Module 



Fig. 6 The overall architecture of the Grace machine 


These tasks are loaded into the P-modules. The required tuples are read 
from the M modules in the form of data streams - stream oriented pro¬ 
cessing. The task then operates on the tuples as the data streams along. This 
concept is rather different from the design principles of other database 
machines, e.g. Gamma, which distribute the database functions to where 
the data is stored rather than streaming the data to the functions. The 
number of functional modules involved in an operation depends on the 
nature of the query, the sizes of the relations and the parallelism required. 

In practice, query execution proceeds in two phases: In the staging phase, 
the relations necessary for the first operation in the query are staged from 
the D to M modules. By invoking the hardware filter at the D module, only 
the relevant tuples are retrieved. This reduces the network traffic tremend¬ 
ously. Once the tuples are staged, the system goes into the processing phase. 
The P modules read the staged tuples from the M modules and perform the 
desired database operations upon the tuples simultaneously in a pipeline 
fashion. 
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Join in Grace is based on a distributed hybrid hash/sort-merge algorithm 
(sometimes referred to as the Grace hash algorithm). The idea is to distribute 
the tuples among the M modules at the staging phase based on the hash 
values of some specified attributes. Tuples in M modules are organised into 
disjoint fragments (or buckets). These buckets of data are streamed to the 
P modules where a local sort-merge join algorithm is applied. Compared 
with the classical nested loop join algorithm whose complexity is of order 
N*M (where N and M are the cardinalities of the joined relations), the 
Grace hashed-join algorithm is less complex. The time to complete the same 
join is of order Yj = i njxmj where N = ^i = i M=^i = imi and s is the 
number of buckets. Moreover, distributing the join operations into X num¬ 
ber of P modules which each module executes in parallel, theoretically 
reduces the execution time by a factor of X. 

The Grace project is progressing rapidly and a fully functional Grace system 
is expected by 1992 - the end of the FGCS research programme. 

4.2 ICOT Delta 

Delta [24] is a back-end relational database machine developed by the ICOT 
research center. It acts as an intermediate prototype system in the Fifth 
Generation Computer System Project (FGCS). The close affinity of rela¬ 
tional algebra to logic programming, the basis of the FGCS software, has 
made ICOT choose relational technology as an intermediate solution to a 
knowledge base system. A loosely coupled logic database environment was 
developed and Delta functions as the external database server. The overall 
system is based on multiple, dedicated Personal Sequential Inference 
Machines (PSIs) which support the logic programming paradigm - in 
Prolog. The PSIs are connected to Delta via a local area network (LAN). 
Delta maintains sets of Prolog facts which are shared by the PSIs. 

In practice, users make queries in Prolog format on the PSIs and sub¬ 
sequently they are converted into query plans. These plans contain Delta 
commands which drive the Delta database machine. The plans are packaged 
into data packets and are sent to the Delta via the LAN. When the query 
data packets are received, the Delta machine extracts the Delta commands 
from them. The commands are interpreted and finally executed. Database 
operations are executed using a merge/sort algorithm in hardware. Resulting 
data, if any, is returned to the appropriate PSIs in the form of data packets 
via the LAN. 

The global architecture of the Delta database machine is shown in fig. 7. 
Delta consists of 5 major processing units: 

1 The Interface Processor (IP) provides an interface to the external systems 
(such as the PSIs via the LAN) and acts as a second means of communica¬ 
tion between the other processing units. 
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Fig. 7 Architecture of Delta/PSI Computer System 


2 The Control Processor (CP) coordinates the operations of all the other 
units. 

3 The Relational Database Engine (RDBE) contains several pieces of 
dedicated hardware that support database operations [21]. The execution 
of database algebra is achieved by a hardware pipeline merge/sort 
algorithm. 

4 The Hierarchical Memory (HM) provides functions for storing, 
accessing, clustering and maintaining disc resident relations. 

5 The Maintenance Processor (MP) controls the initiation and termination 
of the Delta system. It also monitors the states of the system and 
performs system configuration management. 

The architecture of Delta has certain salient features specially designed to 

support database applications. They include: 

• A distributed function multiprocessor configuration - IP, CP, RDBE 
and MP are independent special purpose processors running in parallel. 
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• A relational algebra command interface with the PSI, Prolog hosts - a 
rich set of Delta commands (relational based) is provided. 

• An attribute-based internal scheme for achieving symmetrical database 
access - i.e. the retrieval time of a relation is independent of the attribute 
specified. 

• Dedicated relational database engines - special purpose merge and sort 
hardware in RDBE. 

• A hierarchical memory with large capacity, high speed semiconductor 
memory units - the total memory size is 20 Gbyte which includes 128 
Mbyte of non-volatile semiconductor disc. 

• Enhanced statistics collection functions by incorporating a general pur¬ 
pose processor in the RDBE - by doing so, Delta can execute non 
relational operations, such as aggregate functions, efficiently. 

• Stream processing in which data is processed in a pipelined fashion. 

The PSI computer systems are well established. At present, they are being 
used intensively as software development tools for implementing FGCS 
software. 

4.3 Gamma 

Gamma [9] was developed at the University of Wisconsin. It is a multipro¬ 
cessor back-end relational database machine. It consists of 17 VAX 11/750s; 
each with 2 Mbyte of local memory. The processors are connected to each 
other and to a host computer via an 80 M-bit per second token ring network 
as shown in fig. 8. The host computer is another VAX 11/750 running BSD 
Unix. Only 8 processors have disc storage - 333 Mbyte Fujitsu discs for 
storing database files; they are also used to execute select and update 
database primitives. One of the 9 disc-less processors is allocated for query 
scheduling and global deadlock detection. The other 8 disc-less processors 
are used to execute join, projection and aggregate operations. 

Relations in Gamma are horizontally partitioned across all disc storage in 
the system. By specifying the storage format using the Gamma query lan¬ 
guage gdl - an extension of QUEL - users can distribute the tuples of a 
relation in 4 different ways - round-robin, hashed, range partitioned by key 
attribute and range partitioned with uniform distribution. 

Round-robin is the default strategy. When a relation is distributed using 
this strategy, each disc takes it in turn to store a tuple. If the hashed strategy 
is selected, a randomising function is applied to the key attribute of each 
tuple to select the storage unit. The key attribute is specified in the gdl 
partition command. In the third strategy the user specifies a range of key 
values at each site. Finally, if the user does not have enough information 
on the relation to identify key ranges, the fourth strategy may be used. 
Under this method, if a relation is not already loaded, it is initially loaded 
in a round-robin fashion. Once the relation is loaded, it is sorted (using a 
parallel merge sort) on the partitioning attribute. The relation is then re- 
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Fig. 8 Architecture of the Gamma database Machine 


distributed in a fashion that attempts to equalise the number of tuples at 
each site. Finally the maximum key value at each site is sent to the host 
processor. 

For query execution, Gamma adopts traditional techniques for query pars¬ 
ing, optimisation and code generation. The optimisation process is somewhat 
simplified as Gamma only employs hash-based algorithms for joins and 
other complex operations. Queries are compiled into a tree of operators. At 
execution time, each operator is executed by one or more operator processes 
at each participating site. After being parsed and compiled, the query is sent 
by the host software to an idle scheduler process through a dispatcher 
process. The dispatcher process, by controlling the number of active sched¬ 
ulers, implements a simple load control mechanism based on information 
about the degree of CPU and memory utilisation at each processor. The 
scheduler process, in turn, activates operator processes at each query pro¬ 
cessor selected to execute the operator. The result of a query is either 
returned to the user through the ad-hoc query interface or through the 
embedded query interface to the program from which the query was initiated. 

Gamma exploits dataflow query processing techniques. Each operator in a 
query tree is executed by one or more processes. These processes are assigned 
to a disc and/or disc-less processor by the scheduler process. Except for 3 
control messages - 2 at the beginning of the operator and 1 when the 
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operator has been executed, data flows between the processes executing the 
query and needs no centralised control. 

The architecture of the Gamma database machine is simple: it is imple¬ 
mented using existing hardware systems. Although simple, it provides high 
disc bandwidth without requiring unconventional mass storage devices. 
Furthermore, the distributed disc architecture of Gamma permits the I/O 
bandwidth to be expanded incrementally. At present, a new version of the 
Gamma machine is being developed using an Intel hypercube [9]. 

4.4 Bubba 

Bubba is a parallel distributed computer designed for large data intensive 
applications at the Microelectronic and Computer Technology Corporation 
(MCC, USA) [7]. For database applications, it can be classified as a 
standalone dedicated database computer. (In fact, Bubba is designed to be 
more general purpose and will be used as a mainframe replacement.) The 
overall architecture of Bubba is shown in fig. 9. Bubba consists of a few 
Interface Processors (IPs), up to 1024 Intelligent Repositories (IRs) and a 
few Checkpoint-and-log Interface Processors (CIRs). All nodes are geo¬ 
graphically close. They are integrated with a hypercube interconnection 
network which provides ample bandwidth, short message latency, and low 
error rates. 
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Overall architecture of Bubba 




An IR contains a fragment of the database (see later). During a transaction, 
it executes the required database operations on its database fragments. It 
consists of a disc with controller, a communication processor, a hypercube 
link and a main processor; these components share a local memory. An IP 
receives transaction programs and executes requests from one or more hosts 
and initiates processes which coordinate transaction execution. A CIR per¬ 
forms checkpointing and logging for recovery, frequently in parallel while 
the IR and the IP are in action. 

A database is stored distributedly in several IRs. A transaction is executed 
in multiple IRs. The objective is to bring the program to where the data 
fragments “live”. Transaction execution follows a dataflow strategy: a node 
begins execution of a database operator as soon as enough of the required 
data is available. Results are sent back to the nodes responsible for executing 
the subsequent operator. Parallelism in a transaction is determined by: the 
degree of data distribution - how many IRs are used to store a fragment 
of a data set; and the granularity of pipelining between operators. 
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The number of IRs participating in a transaction varies between applica¬ 
tions. Some applications may be serviced by a few IRs, whereas others may 
require the service of a few tens. On an IR, execution is based on the 
workspace model: updates of a transaction are stored temporarily in a 
private workspace. The changes become permanent at commit time and are 
migrated to disc in the background. A global validation step is required as 
part of the protocol. The storage manager on each IR gives effect to the 
concept of extents: a sequence of blocks physically close to each other. 

A user transaction program in Bubba is expressed in FAD [14]. FAD 
provides an object oriented programming model. It provides user defined 
atomic types, tuples and sets and a set of operators for object manipulation 
which is a superset of the relational algebra operators (i.e. FAD is relational 
complete.) Moreover, FAD provides a number of control operators such as 
while-do and if-then-else. This makes FAD more general purpose than a 
conventional relational language (e.g. SQL). A FAD program is translated 
to PFAD (parallel FAD). PFAD is the target interface to Bubba. It is FAD 
with communication primitives and a parallel model of execution. PFAD is 
expressed in the form of dataflow graphs. Each node of a PFAD graph 
represents a database operation on a data fragment and the arcs represent 
the data dependency between fragments. The arcs also show the transmission 
path for partial results from one set of IRs to another. In practice, nodes 
of a PFAD dataflow graph are converted to threads and are loaded into 
the corresponding IRs. A dataflow execution strategy is adopted, as ex¬ 
plained above. 

At present, a Bubba prototype is implemented on a 40 processor Flex/32 
multiprocessor. Each processor node consists of an 18 MHz Motorola 68020 
CPU, 68851 MMU 68881 FPU, 6 MB local memory, a 150 MB disc and a 
ESDU disc controller. A simulation of the hypercube interconnection net¬ 
work is constructed using 9 MB of common memory. This memory is 
partitioned into buffers and each of the processing nodes is assigned a 
dedicated buffer pool. The nodes only access this pool for messages. 32 of 
the 40 processors are used as IRs. The remaining 8 are used for experiment 
and system controls. 

5 Trends of Database Machine Architecture 

5 .1 A Multiprocessor System 

For cost/performance reasons, database machines are mainly designed for 
large database applications. To handle large applications efficiently, multi¬ 
processor architectures are used. The most important goal in the design of 
multiprocessor database machines is to exploit parallelism as much as pos¬ 
sible with a minimum of control and communication overheads. 


^Enhanced Small Disc Interface. 
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A multiprocessor database machine may be comprised of multiple identical 
general purpose processing elements (e.g. Gamma); or it may be a heterogen¬ 
eous system implemented with different types of processing elements (e.g. 
Delta). The former architecture is more practical and widely used (e.g. 
Teradata DBC/1012). Compared to a heterogeneous system, a multipro¬ 
cessor machine with identical processing elements is more robust and is 
easier to maintain. Scalability is another advantage of this architecture - 
speed and storage performance of a machine may be increased by simply 
introducing additional processing elements. 

5.2 ‘Data Declustering’ and 'Shared-Nothing' Architecture 

In conventional database systems, a large centralised disc system is used to 
contain the database files. Such a configuration gives rise to inefficient 
database performance due to the disc I/O bottleneck. To relieve this predica¬ 
ment, the trend in database machine design is to adopt the technique of 
‘data declustering’. Using this technique, a base relation is divided into 
fragments, based on either a horizontal (row-wise) or vertical (column-wise) 
partitioning scheme. The fragments are distributed and stored in several 
processors - referred to as the ‘home’ processors. During execution of a 
query, database operations need only be directed to the appropriate ‘home’ 
processors. This technique is known as function distribution (i.e. sending 
functions to data rather than data to functions as in normal database 
systems). Function distribution has the effect of sharing the load of the disc 
I/O between multiple ‘home’ processors. The ‘home’ processors may be 
active simultaneously, performing parallel database operations. In the con¬ 
text of database systems, the multiprocessor architecture with distributed 
data (or distributed memory) is often referred to as the ‘shared-nothing’ 
architecture. This architecture is preferred over the ‘shared-memory’ and 
‘shared-disc’ architectures for multiuser database applications. It provides 
higher availability, reliability and scalability [27]. 

There are many possible ways to decluster data. They are based on 4 main 
data placement strategies (see also the section on Gamma): (1) round-robin, 
(2) hashed, (3) range partitioned by key attributes and (4) range partition 
with uniform distribution. Strategies (2)-(4) have the advantage of reducing 
the search space. To achieve that, a set of keys needs to be specified for a 
relation at creation time. This is not a requirement for the round-robin 
strategy. Strategy (1) performs better for non-keyed searches. Therefore, for 
knowledge base applications which requires symmetrical information access 
(c.f. Delta), the round-robin strategy is preferred. An ideal database machine 
supports all 4 strategies. At run time, depending on the current working 
relation, a specific strategy is selected. This is, in fact, the case in Gamma. 


It is interesting to note that simple database applications, such as debit/ 
credit, favour a large ‘degree of declustering’. This is because there is little 
inter-process communication in debit/credit applications. On the other hand. 
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for complex decision support applications, a low ‘degree of declustering’ is 
preferred [25]. 

5.3 Reduced Process and Communication Overheads 

Two major technical difficulties arise from database ‘declustering’. The first 
one is load balancing. Unevenly distributed data can create hotspots which 
in turn may affect system performance. Part of the responsibility of the 
database operating system is to ensure that the machine is efficiently bal¬ 
anced. The second difficulty is the ‘degree of declustering’ [25]. Database 
operations are executed on ‘home’ processors; therefore, the number of 
‘home’ processors involved can affect system performance. In practice, the 
number of processors can only be increased up to a certain point. Beyond 
this point, an adverse effect takes place. This classical diminishing return 
behaviour is caused by an inter-process overhead due to a high rate of 
message passing between separate processes and an intra-process overhead 
caused by overheads in process coordination (such as process startup, switch¬ 
ing and synchronisation). 

To reduce the effect of message passing, a well designed communication 
protocol and a fast communication system are required. The latter can be 
achieved with a high bandwidth, low latency network coupled with a high 
speed network interface unit on each processing node. This feature is exhib¬ 
ited by the Teradata DBC/1012 with its Y-net communication links. 

Overheads for process coordination can be reduced by introducing ‘light¬ 
weight’ processing mechanisms on each processing element. The coordina¬ 
tion of ‘light-weight’ processes (threads) are faster than normal processes 
because less work needs to be done by the kernel. The kernel needs to 
maintain fewer resources. Resources such as the process table, the lock 
table, ... etc, are shared by all threads of the same task. These resources 
could be kept in a common area and need not be stored/restored during 
context switches. The coordination of threads, therefore, is less CPU- and 
memory-intensive. Database transactions are divided into sets of ‘light¬ 
weight’ processes. They are executed in different processors on a ‘shared- 
nothing’ database machine in parallel. Moreover, on each processor, mul¬ 
tiple ‘light-weight’ processes may be executed concurrently. 

5.4 Database Operations in Parallel 

Join is the most complex and time consuming database operation. It can be 
executed efficiently on a multiprocessor system in parallel. There are 3 basic 
multiprocessor join algorithms: the nested loop, sort-merge and hashed join 
algorithms. The nested loop algorithm is the simplest. Its execution time is 
inversely proportional to the number of participating processors. It works 
best when the number of processors is high. Furthermore, since each tuple 
is compared with every tuple, the nested join algorithm easily supports non- 
equijoin. 
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The sort-merge join algorithm is more complex and performs better as the 
operand relations become large. It is implemented in most Japanese ma¬ 
chines using specialised sort/merge hardware (e.g. ICOT Delta). For a 
certain configuration, the addition of new processors causes very little im¬ 
provement in performance with this algorithm. This is due to the high 
overhead caused by inter-processor communications and message passing. 
However the sort-merge algorithm has the merit of utilising another useful 
operator, namely sorting. 

The hashed join algorithm is better when the number of matching tuples in 
the larger relation is small. In that case, the use of bit arrays (as proposed 
in the ICL CAPS [3] and implemented in Gamma) avoids many useless 
accesses to the hashed file. For a given configuration, each of the algorithms 
can excel, according to the characteristics of the operand and result relations. 
Since the join operation is very important in relational systems, the trend is 
to support all the algorithms and at run time, choose the best one by 
estimating the required execution cost. This strategy is adopted by Grace. 

Aggregate functions, which are simple integer arithmetic, are performed by 
the CPUs on the relevant processing elements. The CPUs are general purpose 
microprocessors with extra hardware functionality for the support of distrib¬ 
uted database operations (e.g. fast context switching). 

Selections and updates are performed directly on the relevant 'home’ pro¬ 
cessors. To coordinate multiple accesses, a concurrency control mechanism 
is provided by the operating system on each ‘home’ processor. There are 
several strategies for concurrency control [5]. By far the simplest is the two- 
phase commit locking scheme. Various locking granularities are possible. 
Depending on the applications, a database can be locked at the database, 
relation, page or tuple level. Furthermore, a separate dedicated coprocessor 
could be embedded on each processing element for concurrency control. 
This could save the associated main processor from being interrupted when 
a locked relation is requested by other transactions; thus the main processor 
could concentrate mainly on data operations. 

5.5 Dataflow Execution 

During a transaction, more than one database operation is usually involved. 
At the compilation phase, a transaction is translated into an execution 
program in the form of a dataflow graph, where nodes correspond to 
operations and arcs correspond to dependencies between operations. The 
code for the operations is distributed to the relevant ‘home’ processing 
elements. On a processing node, an operation exists as a ‘light-weight’ 
process (or ‘thread’). The simplest way to run a transaction is to pre-activate 
the ‘threads’ on all ‘home’ process elements at the start of the transaction. 
However, not all ‘homes’ can do useful work at the same time. This is 
because the start of some operations may depend on the results of others. 
Therefore, although all ‘threads’ are activated, some ‘threads’ are simply 
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waiting for results from their predecessors. These waiting ‘threads’ are 
harmful and prevent their corresponding processing elements from running 
other tasks. 

One way to enable waiting ‘threads’ to perform useful work is to use a 
dataflow execution strategy [8]. This strategy is adopted by many existing 
machines, e.g. Gamma. Dataflow execution is based on the notion of dy¬ 
namic activation [2]. Operation ‘threads’ for a transaction are only activated 
when the results of their predecessors arrive. Efficient execution of dynamic 
activation requires fast ‘thread’ switching. When a message containing the 
result arrives at a processing element, the processing element must be able 
to bind this message to the appropriate ‘thread’ rapidly. 

5.6 A Specialised Database Operating System 

Implementation of a DBMS on top of a general purpose operating system 
is inefficient. The inefficiency of this approach is shown in the experiments 
conducted by Hagmann et al. [12]. The only advantage of this approach is 
portability - a database management system can be integrated with an 
existing system easily. Therefore, it is adopted by many commercial vendors 
for developing software database engines (e.g. Ingres from Relational Tech¬ 
nology Inc.). These engines are only suitable for medium-sized system. 
Hardware database machines are built to handle large databases. Their 
operating systems must be specially designed to support the unconventional 
architecture of the machines and the low-level data management. A 
standalone database operating system is complex. To design an efficient 
database operating system, requires careful consideration of the following 
areas [26]; 

• Buffer management (e.g. buffer allocation in a join operation). 

• File management (e.g. data placement, concurrency control). 

• Process management (e.g. multithreading supports). 

• Process scheduling (e.g. dynamic ‘thread’ activation). 

• Process communication (e.g. message passing between threads). 

• Query optimisation (e.g. decide the fastest route for a query). 

At the implementation level, a database machine must provide hardware 
features to support its database operating system. 

6 Conclusion 

This paper reviews the state-of-the-art architecture of ‘now’ (commercial) 
and ‘emerging’ (research) database machines. The architectural features of 
these machines will influence the design of future database machines. Two 
important aspects of database machine design have been discussed: 

• From a practical point of view, integration of the machine with existing 
systems must be simple (software/hardware connectivity); the machine 
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must be able to cope with an expanding work load (scalability); it must 
have good recovery mechanisms to tolerate system faults and errors 
(reliability); and it must provide a means to handle confidential informa¬ 
tion (security). These are vital factors which will influence the acceptance 
of the machine and must be taken into account when designing a 
database computer. 

• At the architectural level, various desirable features are identified. They 
include: the ‘shared-nothing’ multiprocessor architecture to exploit data 
parallelism; database ‘declustering’, high-speed message passing proto¬ 
cols, multithreading (or ‘light-weight’ processes) and the dataflow execu¬ 
tion mechanism for parallel operations; and also a specialised database 
operating system is essential for efficient system management. 

The design factors and the architectural trends discussed in this paper may 
be used as a set of guidelines for designing future database machines. 
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Abstract 

The very high cost of the capital equipment required for the manufac¬ 
ture of modern integrated circuits makes it important that develop¬ 
ment time for each generation of techology is reduced as far as 
possible. Computer simulation is now used to assist in this develop¬ 
ment and STL has been involved in Alvey and ESPRIT collaborative 
programmes to advance such methods. 

Modelling is applied to two classes of problem: the processing steps 
which lead to the diffusion of dopant within the silicon and the 
growth of surface oxides, and the electrical performance of the 
device. Both give rise to coupled sets of non-linear partial differential 
equations which can be solved by adapting numerical techniques 
widely used in other engineering fields such as the finite element 
method. For solution of the problem on two-dimensional sections 
through the devices this results in large sets of algebraic equations 
[4,000-12,000] which have required the development of efficient 
sparse matrix techniques for their solution. To obtain the required 
accuracy care has to be taken in the choice of the mesh and the 
representation of the equations on the mesh in order to have an 
accurate and stable solution. 

These modelling techniques have been extensively used by STC to 
help technology developments. Current applications include the de¬ 
velopment of bipolar technology for Gbit optical fibre repeater use 
and the development of CMOS technologies at 1 and 0.7 ^m. 


1 Introduction 

The rapid advance of silicon technology has enabled the vast growth of 
computation power now available to society. This rapid advance of com¬ 
puter technology has in turn been used in the development of the silicon 
technology. An efficient silicon IC production line is now producing compon¬ 
ents using expensive computer controlled manufacturing equipment and 
managing the production flow with computer based scheduling. Only with 
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these techniques can sufficient control be achieved to ensure the reliable 
operation of circuits with hundreds of thousands of transistors with dimen¬ 
sions close to 1 micron. 

The nett effect is that modern IC manufacturing is capital intensive. It is 
therefore imperative that the time to develop the technology is reduced to 
ensure that the large capital investment is turned into production use quickly. 
To assist in this, computer modelling techniques are now widely used 
throughout the world, and at STL we have been involved in helping advance 
these techniques through collaborations in the Alvey and ESPRIT pro¬ 
grammes. These modelling techniques embed the technologist’s knowledge, 
previously stored on graphs [e.g. oxide thickness v growing time in furnace] 
into numerical code which enables the details of the features which control 
the minimum size of each transistor to be investigated. Thus the techniques 
form a primitive knowledge-based system combined with a powerful simula¬ 
tion capability to answer “what if” questions and thereby enable the next 
generation technology to be developed more rapidly. 

In this article it is intended that the computation of problems encountered 
when building these tools will be discussed. The reader interested in the 
development of the physical modelling, which forms the knowledge base for 
the simulation is referred to Selberherr (1984), Engl (1986). 

2 The Physical Problems of Process and Device Simulation 

When developing a silicon technology, two distinct types of simulation tool 
are used. 


Firstly, we wish to understand how the manufacturing process controls the 
surface topology and the distribution of dopant atoms in the device. Figure 1 
illustrates the cross-section of a bipolar device. If we wish to make smaller 


Base contact formed 
by diffusion of boron 




n doped epitaxial collector 


Polysilicon emitter 
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p doped base 


Field isolation oxide 


n+ doping (buried collector) 


A; diffusion at local oxide edge 

B: diffusion at n+ emitter edge. 

Fig. 1 Cross-section of silicon bipolar device 
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devices it is necessary to reduce the sideways diffusion of the features such 
as local oxide edge [A in Fig. 1] or the n+ emitter doping region [B in 
Fig 1]. The steps in the manufacturing process which control these features 
are the ion implantation procedure which introduces the doping atoms, and 
the high temperature anneals which subsequently diffuse them. The simula¬ 
tion of these steps is therefore the key part of process simulation. 

Secondly, given the device structure, we wish to understand how the device 
will perform electrically. How fast will it switch? How much current can the 
transistor supply? What voltage can be applied before the device breaks 
down? The device simulation stage therefore requires the solution of the 
equations which control the distribution of potential and flow of currents 
within the device. 

Computationally, the greatest challenge for process simulation is the 
diffusion process which controls the motion of dopant in the silicon during 
the anneals and the rate at which oxygen from the ambient gas during the 
anneal reaches the surface to react with the silicon to form silicon dioxide. 
These processes can be represented by Tick’s equation, 

dcjdi = div (D grad(c)) 

where c represents the local concentration of oxidising species or dopant, 
whilst D, the appropriate diffusivity, is now known to be a complex function 
of concentration of all of the diffusing species. Thus the model equations 
are non-linear, coupled partial differential equations with a specified distribu¬ 
tion at the start of the anneal. To further complicate the model, the oxidant 
will only diffuse within a surface oxide layer. When it reaches the silicon it 
will react to create more oxide, thus changing the location of the interface, 
the geometry of the oxide and possibly introducing stress into the oxide 
[Poncet (1985)]. These processes are illustrated in Fig. 2. 
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Fig. 2 Some of the phenomena encountered during process simulation 
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In the device simulator, the distribution of potential is determined by Pois¬ 
son’s equation and the potentials applied at the contacts to the device. Thus 

div (grad( ^)) = - ^^oq[P - n -h - NJ 

where ^ is the internal electrostatic potential, 

e^o is the local dielectric constant 

p,n are the local hole and electron densities 

Nd, Na are the local density of donor and acceptor impurities 

q is the electronic charge. 

The current flow within the device simulator is controlled by the equation 
for continuity of carrier density, and the equation which represents hole 
flow due to both drift and diffusion. 

ap/a=-V<, div(Jp) + G 

Jp= -q^[P grad(T) + '‘'^/, grad(p)] 

where Jp is the local hole current density [a similar expression can be derived 
for electrons] 

p is the local hole mobility 
k is Boltzmann’s constant 
T is the absolute carrier temperature 
G represents electron-hole generation or recombination. 

These mechanisms are illustrated in Fig. 3. 
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Fig. 3 Some of the phenomena encountered in device simulation 
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Thus for device simulation the problem can be expressed as a coupled set 
of equations which are non-linear since the mobility and generation are 
functions of the carrier concentration and potential [Selberherr (1984)]. Thus 
the equations for both process and device simulation are very similar in 
form. 
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One of the most important features of the equations for silicon technology 
modelling is that they represent conservation of a physical quantity. In the 
case of the process models that quantity is the diffusing species; the equations 
for current flow conserve current and carrier density whilst the Poisson 
equation conserves charge. These conservation properties are physically 
important. We expect the current that flows into one terminal of a device 
to flow out of the others under steady-state conditions, and it is therefore 
important that they are preserved by the solution techniques used. 

The similarity of the equations means that comparable techniques can be 
used for both process and device simulation. In practice, the computation 
techniques to solve the process problem have developed less rapidly; this, I 
believe is due to the fact that there is still a great effort required in developing 
the physical models for diffusivity whilst the physical models for device 
simulation are better understood. There has been a push towards improving 
computational aspects. This push has resulted in the recent development of 
simulation tools capable of modelling a three-dimensional device (rather 
than two-dimensional sections through it) in a tolerable time on a minicom¬ 
puter. Much of the following discussion on computational aspects will 
therefore be centred on device simulation in which we have been active at 
STL in the developments in the Alvey device modelling project (VLSI/034) 
and in the collaborative development of a three-dimensional device simulator 
in ESPRIT project 962. 

3 Mesh Generation 

In common with many other engineering problems which can be expressed 
in the form of partial differential equations, the most practical way to obtain 
a quantitative solution of the problem is to superpose a mesh of nodes over 
the device (for example see Zienkiewicz, O.C. 1977). This enables the partial 
differential equation to be reduced to a set of algebraic equations for the 
value of the quantities of interest at each node. These quantities can then 
be interpolated between mesh points to get a representation of the solution 
throughout the device. 

The properties of this mesh of points can be summarised thus: 

1 The points must cover all the device, even allowing interpolation into 
corners that may result from the manufacturing process. 

2 The points must be sufficiently close together to allow accurate interpola¬ 
tion; this is especially true where a quantity is varying rapidly. 

3 Too many points will lead to slow computation of the solution. 

4 The points must be connected topologically in a way that ensures a 
stable and accurate solution. 

Figure 4 illustrates two types of mesh used for simulation. 
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a/ Finite difference 



b/ Finite element 

Fig. 4 Types of mesh employed by semiconductor simulators 

The ‘finite difference’ mesh is characterised by mesh lines that pass directly 
from one side of the device to the other. This type of mesh is extremely easy 
to construct. If the device is not rectangular it is possible to find a mathemat¬ 
ical transformation that maps the device onto a rectangle and construct the 
mesh on the transformed domain. If the mathematical transformation can 
be achieved with a conformal mapping (Penumalli B.R. (1983)) then the equa¬ 
tion set is not overly complicated by the mapping. This technique is often 
used for the solution of diffusion of dopant under an oxide where the inter¬ 
face is smooth (as in Fig. 2). An example of such a mesh is shown in Fig. 5). 



Fig. 5 Conformally transformed mesh in silicon under a selectively oxidised surface 

To meet the second requirement of adequate mesh density, the only recourse 
is to insert more mesh lines. With a finite difference mesh this can be wasteful 
as the extra mesh density is often only needed at one place in the device. 
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say at the top; however, with finite difference the mesh must be inserted 
from top to bottom. 

The rectangular geometry of the mesh provides a stable numerical ‘discretis¬ 
ation’ and because of the regularity of the topology, managing data on a 
finite difference mesh is straightforward. 

The finite element mesh is characterised by a union of polygons which fill 
the device. For simplicity and generality, triangles are usually chosen in two 
dimensions. This allows any general boundary to be represented by a 
piecewise linear approximation. With this type of mesh, any domain can be 
represented without a transformation and mesh points can be added locally 
if extra refinement is needed. 

At first sight this appears to be the ideal choice for all meshes. However, 
managing the data on a finite element mesh is not so straightforward and 
generating the mesh is very difficult. To exploit the mesh fully requires 
considerable user intervention to select the areas where mesh refinement is 
required. Furthermore, the requirement that the mesh topology gives rise 
to an accurate and stable solution can be shown to require meshes that 
contain no (or at least very few) obtuse angled triangles. Despite these 
problems, finite element meshes are frequently used, though the most suc¬ 
cessful variants are those that build their mesh from a rectangular grid such 
as that shown in Fig. 6, which represents a bipolar transistor where extra 
mesh refinement has been placed in the base region and at the pn junctions. 

The finite difference method can be extended to three dimensions fairly 
simply, but it must be noted that the problem size increases rapidly. For 
two-dimensional problems 2,000-4,000 mesh points are usually required for 
a typical finite difference mesh. In three dimensions this increases to 
50,000-100,000. The inability to refine the mesh locally is now a severe 
disadvantage. 

To implement a finite element mesh in three dimensions, the logical extension 
would be to use tetrahedra to fill the space. 

In the collaborative ESPRIT project (962) we adopted a compromise posi¬ 
tion where rectangular bricks fill the bulk of the device but tetrahedra are 
used to enable local mesh refinement and to represent the boundary geo¬ 
metry. This approach was taken because of problem size [it takes five 
tetrahedra to represent each rectangular brick] and because of the slowness 
of calculating geometry-related factors for tetrahedra. 

So far the comments on mesh generation are based on the concept of a 
fixed ‘a priori’ mesh. This relies heavily on it being possible to identify a 
mesh which is accurate enough and based on the user’s ‘feel’ of how the 
problem will turn out. Inevitably, to ensure the mesh being accurate enough, 
extra mesh points are included, leading to longer simulation times. In 
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Polysilicon emitter 


- 0.5 - 


Base contact 



0.0 1.0 2.0 3.0 4.0 5.0 6.0 

Fig. 6 Finite element mesh representation of a polysilicon emitter bipolar transistor 


addition, as the simulation progresses, the domains which require a fine 
mesh to resolve the variable of interest move through the device. This 
situation is encountered when dopant is being diffused into the silicon from 
the surface and the dopant depth increases monotonically as the diffusion 
time increases. 

Current simulation still relies on a cautious, fixed mesh and hence longer 
simulation times. Within the Alvey process modelling project [VLSI/066] 
the moving finite element method [Miller K 1981] which is used to simulate 
shock fronts, was investigated for this problem. In the moving finite element 
method the mesh topology is kept fixed but the nodes are allowed to move 
with the diffusing species. Limited success was obtained, but the difficulty 
of choosing the topology of the initial mesh so that it could move successfully 
with the advancing profile meant that the method could never be used with 
great confidence. 

The second approach to automating the mesh is to add nodes wherever the 
interpolation is inaccurate according to some criterion which can be deter¬ 
mined by the software. This approach can be implemented very easily in a 
finite difference mesh if a suitable criterion for error can be defined. 
MINIMOS [Selberherr 1979] is probably the most widely used device simula¬ 
tion program available and it automatically inserts lines wherever the poten¬ 
tial is changing rapidly. Thus the user need never get involved with the mesh 
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and any extra computation time is recouped through the reduced time the 
user has to spend preparing his input. 

The same techniques are not as yet readily available with finite element 
meshes. One of the major problems with refining a triangular mesh is 
maintaining the ‘quality’ of the triangles. For the solution of partial differen¬ 
tial equations on a triangular mesh, a poor ‘quality’ mesh is one which 
contains many obtuse triangles. Figure 7 shows how the quality of a triangu¬ 
lar mesh can be rapidly degraded by refining an equilateral triangle just 
twice. To overcome this in the collaborative ESPRIT project, we have 
developed a refinement scheme built around triangles generated from a 
rectangular mesh. To keep the finite element advantages, local refinement is 
enabled by allowing two types of rectangle. The first type has four corner 
nodes and can be divided into two triangles by insertion of either diagonal. 
The second type has a fifth node inserted at one edge and is divided into 
three triangles [Fig. 8]. This allows the termination of mesh lines at a 
rectangle edge. To prevent the central triangle in the second type from being 
obtuse, it is a matter of simple geometry to show that the termination of a 
mesh line cannot be permitted on the longest edge of a rectangle with aspect 
ratio greater than 2. With this rule it becomes simple to generate a mesh 
whose ‘quality’ does not get progressively worse by refining the underlying 
rectangular structure. The mesh shown in Fig. 9 captures a p-n junction by 
an automatic refinement procedure based on this rectangular structure. This 
concept is now being extended to cover three-dimensional simulation do¬ 
mains where it is very important to have an automatically adapted mesh as 
it is impossible to view a three-dimensional mesh to judge its adequacy. 


division of a triangle 
into 4 maintains shape 




Fig. 7 Degradation of triangle ‘quality’ through refinement 


A terminating mesh line 
causes rectangle to be 



Fig. 8 Two types of rectangle used to build an adaptive finite element mesh 
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DEVICE DIMENSIONS 



Fig. 9 Depletion region around a p-n junction captured by an automatically adapted grid 

4 Interfacing 

Historically, process and device simulators have been independently de¬ 
veloped. This poses the user with the problem of providing an interface 
which enables data describing the device geometry and the doping to be 
passed from the process simulator into the device simulator or for results 
from either simulator to be displayed graphically in a consistent form with 
a single set of commands. Furthermore the native input language to control 
the simulator can be very different from one code to the next. Within the 
semiconductor simulator field there is no defined standard nor has any one 
piece of software gained such a dominant position that it provides a ‘de 
facto’ standard. Practically, most large companies have developed some 
form of interface software for the tools they use. At STL we have developed 
a central interface programme which enables data to be taken from one 
code, displayed and/or converted to the input format of a second code. 

Two other interfacing solutions are emerging. In the United States, simula¬ 
tion software is sold by small software companies (eg. TMA) who have 
taken University developed software, polished it and provided interfaces. 
These interfaces, however, lock the user into software provided by that 
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company. In Europe, EEC sponsored collaborative programmes are 
bringing the groups developing the software tools together and forcing 
interfaces between the tools to be written. The nett effect is to ensure that 
the partners of the projects have a fully interfaced set of tools; but to those 
outside the projects, it is unlikely to provide tools any differently from the 
US approach. 

The experience from modelling semiconductor devices illustrates the import¬ 
ance of ensuring from the start that all necessary interfaces are identified 
and the necessary routes are available to put them in place. 

5 How to Solve the Equation by Computer 

The methods used to solve the equations by computer are based on tech¬ 
niques at the forefront of the very mathematically based field of numerical 
analysis. The solution procedure can be broken down into three distinct 
areas: 

• Reduction of the partial differential equations to a set of algebraic 
equations associated with the nodes of the mesh. This is known as 
‘discretisation’. 

• Solution of the set of non-linear algebraic equations by an iterative 
solutions of linear approximations to the equations. 

• Solution of the large set of linear equations. 

Whilst it is inappropriate to follow these topics through in detail in this 
article, further information is presented in the appendix and details can be 
followed up in the references. In this section I wish just to present some of 
the key directions pursued in developments in which STL has been involved. 

The ‘discretisation’ of the semiconductor problem is strongly based on the 
requirement to conserve key physical quantities. For example, once an 
impurity has been introduced into a silicon wafer by ion implantation, 
subsequent heat treatment will redistribute the impurity but not change the 
total quantity unless some diffuses to a surface from which it can escape. 
This conservation is achieved by ensuring that the ‘discretisation’ approxim¬ 
ates the physical fluxes which flow from node to node thus ensuring that 
any flux which leaves one node will be transferred to its neighbours. 

The set of algebraic equations which result from the ‘discretisation’ of the 
semiconductor problems is always non-linear. This is at its most severe when 
trying to simulate the current flow within a device, as the local carrier 
density is a rapidly varying (exponential) function of the potential. This 
should come as no surprise, as it is this rapid dependence of carrier density 
on potential that enables semiconductor devices to make such good switches 
and amplifiers. The solution of such a set of non-linear equations is achieved 
by a traditional iteration technique originally due to Newton where an initial 
guess is improved by looking at the slope of the non-linear function at the 
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current guess. This technique works well for the semiconductor problem but 
developments have been made to: 

• improve the initial guess based on our understanding of the problem. 

• allow us to compensate for some of the known curvature about our 
current guess as we try to improve it. 

• give us improved criteria to state when the iteration procedure can be 
terminated. 

The effective solution of the non-linear equations relies on having an efficient 
linear solver to calculate the update that needs to be applied to improve the 
current guess. However, since a typical problem has 4,500 - 12,000 equa¬ 
tions, the linear solver must perform well on large problem sets. A special 
feature of linear equations that are generated from partial differential equa¬ 
tions is that they are ‘sparse’ i.e. each equation involves only a few variables, 
those at the neighbouring nodes. The combination of sparse storage schemes 
and efficient modern linear algebra techniques based on iterative methods 
have been demonstrated in our projects to represent a significant step 
forward in performance for large problems. This advantage comes because 
the time to find a solution increases less rapidly with problem size than 
conventional techniques. On a symmetric test problem the time taken was 
given by: 

[(no.of unknowns)/1000]^-^ seconds on a VAX 8650. 

6 An Example 

At STL the modelling techniques have recently been applied to the develop¬ 
ment of a 1 pm CMOS technology at STC Components. One of the import¬ 
ant design issues in CMOS technology is the engineering of the pMOS 
device doping to ensure that, even when the maximum bias is applied to the 
drain terminal, if the gate is turned off no significant leakage current flows. 

The initial process flow drawn up with the process engineers was simulated 
and the hole density within the device is shown in fig. 10a. The two regions 
of high hole concentration either side of the device are the source and drain 
contacts and the ridge of holes connecting them represent a leakage path 
beneath the surface of the device. This conduction beneath the surface is 
known as punchthrough and by inspection of the doping profiles in the 
device it was simple to identify that this was caused by excessive diffusion 
of a surface boron layer during the critical gate oxidation step. It is worth 
emphasising the point that without simulation there would be no way that 
the position of the leakage path could be identified by measurement. 

In this case the punchthrough is not severe, but we took the opportunity to 
move the process away from a latent problem by exploring the different 
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Fig. 10 Distribution of holes in a 0.8 urn p-MOS device with -5V on the drain but the gate 
turned off 

process options which would influence the profile using a one-dimensional 
process simulator where run times take a few minutes on a microVAX. 
The process was reconfigured with the surface boron layer being created 
after the gate oxidation. The hole concentration within the device no 
longer displays the ridge from source to drain, indicating that the modifi¬ 
cations were successful. The two-dimensional simulations required up to 
two hours of CPU time on a VAX station but the results are obtained suffi¬ 
ciently rapidly that a particular process option can be investigated by an 
engineer using simulation tools in about one week. 

At STL, about 3 man-months of simuation work have been used to provide 
a process flow which we predict will provide n- and p-channel devices of 
close to target threshold voltages [-I-0.8V, —0.8V respectively]. The devices 
will not show punchthrough behaviour and the isolation between devices 
will resist breakdown at maximum supply rating. 

Even with well planned experimental work, to reach this stage would take 
3 or 4 batches of silicon and at least 6 months after the necessary equipment 
has been installed. Thus modelling provides a significant saving after al¬ 
lowing for the modest computational costs and the cost of maintaining and 
developing the software. The latter costs are reduced by purchasing the 
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b/ final process adjusted to suppress leakage. 
Fig. 10 


basic programs from companies which provide maintainance, and by devel¬ 
oping software within collaborative projects as this allows sharing of costs 
with other industrial users. 

The simulations of the 1 pm CMOS process have not yet been proven, the 
first silicon is still in processing. Nevertheless the modelling tools have been 
proven on earlier technologies to give confidence in the accuracy of the 
simulators used. In particular, considerable experience has been obtained in 
simulation of the key MOS parameters of threshold voltage where the 
simulated value has been typically within 100 mV of the measured value. 
Considerable effort has also been put into accurate models for the mobility 
within the silicon, and above threshold the current can be predicted to better 
than 20%. This accuracy is sufficient to give confidence in the performance 
the first devices will have and we are expecting only one minor iteration to 
bring us to our target process. 

7 Final Comments 

I have given an overview of the general mathematical models we use to 
simulate semiconductor processes and devices, and the techniques we use to 
solve the equations. The mathematical models are similar to those used in 
other fields, such as cooling of circuit boards, or flow of oil from an oil 
reservoir. Numerically, the distinction between the problems is often better 
made not so much by the model equations as by the resulting non-linearity 
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of the problem or the complexity of the geometries that need to be meshed. 
The solution techniques adopted for all such problems are very closely 
related. 

The models discussed are now widely used to help understand the limitations 
of small high performance devices and to speed up the development of such 
devices. At STL we have made considerable use of the modelling tools to 
understand how to improve the speed of the bipolar devices manufactured 
at STC Semiconductors, Foots Cray to meet the Gbit requirements of future 
optical cable technologies. As illustrated, we are developing smaller CMOS 
technologies with the help of the modelling expertise. This will allow us to 
make devices with feature sizes down to 0.7 pm in the next two years. As 
we approach these dimensions, it is clear that not only is the modelling of 
the diffusion processes and device operation important, but an improved 
understanding of film deposition and etching processes is also required. This 
will lead to a requirement to model the operation of some of the processing 
equipment. The move towards higher speeds in silicon technologies will also 
force silicon engineers to extend their modelling towards that used by 
microwave engineers. Thus it is envisaged that in the future the scope of 
modelling used in the simulation of silicon technologies will increase in order 
that higher performance devices can be made. 

8 Appendix 

‘Discretisation’ 

Semiconductor device simulation poses some particularly tough problems 
for the numerical analyst trying to convert the partial differential equations 
into a finite set of equations. Both the process and the device simulation 
processes require the ability to cope with a very large change in the key 
variable. For example, the doping in the emitter of a bipolar transistor will 
change by two or three orders of magnitude close to the base junction, 
whilst the electron concentration can change by more than ten orders of 
magnitude at the same place. This constraint has prevented the adoption of 
the sophisticated ‘discretisation’ techniques that have been developed e.g. 
higher order finite elements. In fact, the same principles are used for 
‘discretisation’ of the equations whether on a finite element or finite differ¬ 
ence mesh. 

The underlying concern is to ensure that a consistent picture for conservation 
is established. Thus the discretisation will maintain the conservation of 
current, dopant, etc. This is achieved by building up a flux balance equation 
at each node, as illustrated in Fig. 11. At each node (i) a box is drawn 
around that node that encloses all the area which is closer to node i than 
to any other node. The edges of this box are the perpendicular bisectors of 
the lines ij joining i to its nearest neighbours j. Now the form of the equations 
which represent the physics of the processes involved is. 


div F = A 
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FOR each triangle with ncxje i DO 
set up 2 d„ = V, A 
ENDDO 

Fig. 11 The box scheme to assemble div(F) = A 

To form the discrete set of equations we wish to approximate this equation 
using only the values of the variables at the nodes of the mesh. In the 
discrete form of the equations we actually solve a weaker form of this, since 
we cannot ensure that this equation is true everywhere in space [in a finite 
mesh]. We insist that 

J div(F)dV= j AdV 

boxi boxi 

Thus we are ensuring that this equation is solved in the average sense on 
each box. The left hand side can simply be transformed using the divergence 
theorem: 

J Fdr= j AdV 

box edge box i 

To be able to use this equation we have to make further approximation 
since neither A nor F is known throughout space. A at node i is assumed 
to be a good approximation to the average over the whole box whilst F dF 
is approximated by flux along the line ij [which can be calculated from the 
variable at nodes i and j] and the width of the edge djj. Thus we can write 
the equation as, 

Zd, F, = VA 

j 

Thus at each node i the problem will be represented by one equation for 
each variable. Each of these equations is (in general) non-linear and involves 
the variables at node i and its immediate neighbours j only. This defines the 
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topology of the numercial problems and I shall return to this when con¬ 
sidering the impact of problem size. 


It is worth noting that the global equation for each node can be set up one 
node at a time if the mesh is stored in a way that gives easy access to each 
of the neighbouring nodes j. This is the standard approach for a finite 
difference mesh. 

With a finite element mesh the usual approach is to note that each element 
[assumed for sake of argument to be triangular] will have a contribution to 
make to the equation at three nodes. The complete equation at any node is 
made up of the sum of contributions of all elements containing that node. 
To generate the whole set of equations, it is simply necessary to pass from 
element to element in turn generating each element’s contribution to all 
three nodes and adding these contributions into the relevant model equation. 
Thus the flexibility of the finite element method is obtained, since we only 
need to consider discretising the equation on an individual element basis. 
This latter point can also be shown to be true even if there is a change in 
material as we pass from element to element, and so the discretisation is 
completely decoupled from the geometry. 

A final comment is related to the calculation of the flux passing from node 
i to node j. The discretisation method will work well provided this flux is 
not rapidly varying from element to element. Scharfetter and Gummel (1969) 
exploited this fact when they demonstrated that it was possible to make a 
sensible discretisation of the device equation even in the presence of a rapidly 
varying electron or hole density. This occurs in a forward-biased p-n diode, 
for example, where there can be a very rapid change in carrier density as 
we pass through the depletion region, yet the current flow is almost constant. 
Thus, when calculating the current flowing from i to j from 



it is not adequate to use linear difference to approximate grad(p) but a 
variation of p should be assumed between the nodes that keeps Jp constant. 
This leads to a current flowing between nodes i and j. 


_ q + [^]j[p.exp(q4>/nT)r 

Lij[exp(qT/kT)]| 

• where [f]j = fj — fi 


The extra complexity of this equation is essential because of the accuracy 
and stability it brings to the solution of the device equations. This approach 
has been adopted in all device simulators in use today, which demonstrates 
the power of the technique. 
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The Non-linear Iteration Procedure 


The iteration procedures commonly used in the device simulators are illus¬ 
trated in Fig. 12. The fully-coupled method, or Newton method, solves all 
the equations together {F{u) = 0) and uses the derivative of these equations 
with respect to the variables (w) to guide the update procedure. Schematically 
this can be obtained by truncating a Taylor series; thus it is required that: 

F(u-h(5M) ^ F{u)-\-dFldudu = Q 
hence du = — [dFldu]~^F{u) 




Solva 

Pol«3on*K Equo tton 


SqIv« Bactron I 
Continuity Equotlcn | 



Fully Coupled 
Approach 


Gummel 

Approach 


Fig. 12 Iterative schemes employed by device simulators 


Note that as there are n equations to be solved (three for each mesh point) 
and n variables, dFjdu is an n by n matrix. For problems of ^^1600 mesh 
points solving the above is expensive. The fully coupled process requires a 
good initial guess from which to converge, but once the updates in potential 
are less than 25 mV, rapid (quadratic) convergence is guaranteed and 
machine accuracy can be achieved in a further four iterations. 

The alternative procedure is due to Gummel (1964). In this procedure the 
equations are solved sequentially. However, this ignores coupling between 
the equations, so the procedure is repeated until convergence. Because this 
procedure does not generate such a large matrix to invert, it is more 
economical per iteration than the Newton procedure. Moreover it converges 
better from a poor initial guess. However, it does not display quadratic 
convergence at the end of the iteration and is therefore more difficult to 
terminate. 

The demands of problem size mean that the sequential or Gummel procedure 
is usually preferred for device simulation. However, many simulators mix 
the Gummel procedure and the fully-coupled procedure, exploiting the 
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greater economy of the Gummel procedure to provide a good initial guess, 
and then obtaining rapid convergence by switching to the fully-coupled 
scheme. 

It should be noted that considerable care has to be put into the conditions 
for terminating these iterative procedures. Two points need to be considered 
when defining the truncation. Firstly, the same absolute accuracy is not 
always required at every point in the device. For example, where the carrier 
density is 10^°cm“^ a figure of 10^® cm"^ is accurate, but this would be 
completely inadequate where the carrier density is only 10^^ cm"^. 

Secondly, it is attractive to monitor F(u) which approaches zero near the 
solution. However, the interpretation of F(u) at each node and for each 
equation is not automatically the same. This is essentially the problem of 
trying to compare apples and oranges. It is possible to say the equations 
are solved with sufficient accuracy if all components F(u) are less than a 
given tolerance, but only if each equation at each node is suitably weighted 
to give a fair comparison. Suitable transformations of the equations which 
achieve this are discussed in a detailed review by Polak (1987). 


The Linear Equation Solution 

Sparse storage techniques are fairly widely available, the general principle 
is to store an ordered list of the non-zero matrix elements and a list of the 
row and column indices of each element. The methods for storing the row 
and column indices are a trade-off between storage space and ease in 
performing matrix arithmetic with the resulting matrix. The technique we 
have adopted in the three-dimension simulator is based on the work of 
Fichtner in Engl (1986). It has the advantage that it is suitable for use where 
there are several equations to be solved at each node of a mesh. In this case 
the sparse structure represents only the mesh topology. However, each 
element stored is no longer a scalar but is a small block matrix (m x m) 
where m is the number of equations to be solved at each node. This has the 
added advantage that the sparsity pattern does not vary as the number of 
variables at a node increases. It is also mathematically straightforward to 
perform all matrix operations using these submatrices by simply replacing 
all scalar operations with their equivalent matrix operations. 

To solve the matrix equations, the conventional techniques used for small 
matrices such as LU decomposition [Wilkinson (1965)] are not available as 
they introduce extra non-zero elements into the matrix. Iterative techniques 
provide a means of solving large families of equations without having to 
introduce extra non-zero elements. To illustrate the iterative technique con¬ 
sider the equation. 

Ax = b. 
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If we have an approximation to the solution x^. We can define a residual 
r„ = b-Ax„ 

If we can define a simple operation which approximates to the inverse 
of the matrix A we can write 

x„ + i-x„2rA-'r„ 

and here we can calculate r^ + i etc. until we have an adequate solution. The 
success of this method relies on the suitable choice of A"^ so that it gives 
a rapid convergence and is economical to calculate with the sparse matrix 
structure. When the matrix is symmetric, positive definite and an m-matrix 
[Polak, 1988] the technique of ICCG [incomplete Cholesky conjugate gradi¬ 
ent] due to Meijerink [1977] proves a very reliable and robust scheme. 
However, in general our problem is not symmetric and there has never been 
as clear a choice for asymmetric matrices as there is for symmetric matrices. 
We have adopted the CGS [conjugate gradients squared] technique of Mark¬ 
ham [1983] and applied an incomplete LU decomposition to precondition 
the problem. This has given reliable results. 
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Abstract 

The real time system described provides the soft functionality for the 
Node Support Computer of the SX Node which was described in the 
previous issue of the Journal. The designers’ aims for the project - 
known internally as ISA for Initialisation and Support Application - 
were to produce a real time system of improved quality and at the 
same time to increase their own productivity. These objectives were 
achieved by using the Ward and Mellor Structured Methodology 
supported by the proprietary design capture tool Excelerator. 

The background of ISA is recounted and the reasons for choosing 
the methodology and how it was introduced into the project are 
explained. The analysis and design phases of the project are then 
described, emphasising the Ward and Mellor features employed and 
the use of Excelerator. Finally some broad conclusions are drawn 
from the success achieved through the use of both methodology 
and tool. 


1 Background 

In 1987 the project was faced with the challenge of producing a complex 
Real Time System. Statistical evidence from the previous project (OSA) 
[Saxon 1986] demonstrated an imbalance with regard to the various principal 
Lifecycle Model phases. Insufficient time had been spent on the analysis and 
design phases which had resulted in significantly longer times for the coding 
and testing phases. Research [Macro and Buxton 1987] emphasised the 
importance of the analysis and design phases in reducing timescales and bug 
count. It also highlighted the previous lack of sufficient effort on these 
phases. 

It was therefore felt that emphasis on the analysis and design phases would 
offer major improvements in product quality, a reduction in overall time- 
scales and a reduction in the bug density of the product delivered to 
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Integration. The selection of an appropriate methodology and support tool 
is discussed later but their introduction added additional complexity with 
respect both to staff training and to tuning the methodology to the specific 
problem domain of the product. 

This paper shows how the chosen methodology was introduced and sub¬ 
sequently used in the analysis and design of this complex real time system. 
It does not describe either the methodology itself or the design support tool 
which was used by the project, though a summary of the methodology is 
included. 

1.1 The product 

The product, ISA, is the Initialisation and Support Application which is 
resident in the Node Support Processor (NSX) of an SX Node (SX being 
the large Mainframe first marketed by ICL in 1990). 

The main ISA functions are - 

• Control of Initial Program Load (IPL). 

• Error Management of Fatal Node Hardware Failure (Photo). 

• Error Management of Fatal Node Software Failure (Dump). 

• Support of In-Line Recovered Node Failure. 

• Support of Remote Diagnostic Access to the Node (VISA). 

• Support of Ancillary Units ie. power and coolant control systems, 
cabinet displays and switches. 

• Support of Operational Node software ie. provision of Software Watch¬ 
dog and Non-Volatile Store. 

ISA is the evolutionary sucessor to a set of three applications which provided 
similar functions for earlier versions of Series 39 Nodes. It is based on and 
is structurally very similar to one of these applications, OSA (Operational 
Support Application) which was a Multi Task application. A Multi Task 
solution offers one effective means of partitioning functionality especially in 
a real time situation involving multiple sources of events and process con¬ 
currency. 

The final product is approximately 17,500 lines of code and has cost nearly 
30 man years of efforts from High Level Analysis and Design through to 
Customer Release. It is written in PLM86 and the processor within the 
Node Support Computer is an Intel 80286. 

1.2 Need to improve 

There was a low perceived value attached to Support Processors which 
paradoxically had been complex and costly to produce as bespoke hardware 
and software solutions. There was a view that by moving aspects of the 
functionality into node software and Picode (microcode) and by making the 
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node hardware self initialising and self diagnosing, the Support Processor 
could be designed out. 

These views dominated early SX system design and the production of an 
evolutionary product in the Support Processor area was not considered to 
be the way forward. Despite this, as early SX System Design progressed 
major gaps were found in the traditional Support Processor areas of IPL, 
Error Management and Remote Diagnostic Access. It was then decided that 
an evolutionary product was needed despite the fact that some functionality 
had been successfully moved into node software and Picode and the node 
hardware had been designed with ease of initialisation and diagnosability 
as design constraints. 

A requirement on the ISA Project was to improve productivity and delivered 
product quality from that achieved with the earlier equivalent products. To 
meet this requirement decisions were made to put increased emphasis on 
the analysis and design phases, to introduce a design methodology and to 
introduce design support tools. The choice of methodology and tools is 
considered in Section 2. 

1.3 Common house style 

Within OSA there had been successful use of a “house style” for design and 
implementation (eg documentation standards, code style and standards). 
This had enabled easy movement of staff within the project and had en¬ 
hanced the effectiveness of design reviews and desk checking of code. 

A similar approach was adopted for ISA covering design, implementation 
and the selection of the appropriate parts of the chosen methodology. 

2 Adoption of new methodology 

There is no alternative to the use of a methodology. A choice can however 
be made between an explicit formal methodology and an implicit Traditional 
and Common Sense (TAGS) methodology. A major problem with TAGS is 
the individual person’s interpretation of “common sense”. Common sense 
is paradoxically not common (ie shared) at all and therefore TAGS relies to 
a large extent on experience and personal intuition. 

Many organisations have endeavoured to develop their own methodologies, 
building upon their present tools and techniques’, however as stated in 
[Maddison 1983], “A complete methodology specification may be impossibly 
long to write and teach, and to cover every possible real situation would 
waste developers’ time during training”. 

It therefore seemed sensible that the ISA Project should consider the adop¬ 
tion of an established and proven methodology. There is no formal method 
to compare design methodologies. Certain non-rigorous classifications exist. 
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but essentially a methodology is optimised for a particular problem domain. 
The choice of a methodology and its introduction are discussed below. 

2.1 Choice of methodology 

ISA is an example of a Real Time System (RTS), and displays the following 
typical characteristics. 

a) Sensors which continually report the state of the various components 
of the system and its environment. 

b) Functionality to allow the system to react to changes in the environ¬ 
ment (eg. sense a breakdown and implement a corrective action). 

c) Concurrent processing of multiple inputs/outputs etc. 

d) Being aware of and responding to events. 

A list of prime objectives was drawn up to serve as input to the selection 
of a specific methodology. This list was also used later as a basis for the 
evaluation of the software development process. 

2.1.1 Prime objectives 

1 The methodology must be graphic in nature. Pictorial representation has 
been proved to be more easily understood and meaningful. 

2 The graphical system must be ‘rich’ enough to convey the design, easy 
to understand and use as few symbols as possible. 

3 The chosen methodology must run on a design capture tool, the heart 
of which must be a data dictionary. Any attempt to use a structured 
technique without a data dictionary at its heart is likely to be unsuc¬ 
cessful. 

4 The methodology must be applicable to the analysis and design of a 
RTS. It must provide for the modelling of events, parallel processing 
etc. 

5 The methodology must distinguish the “Essential” features of a system 
(ie. the characteristics it would have if implemented with perfect techno¬ 
logy) from its “Incarnation” (ie. eventual implementation). 

6 The methodology must be expandable with problem size and through 
different levels of abstraction. 

7 The methodology must provide the ability to perceive the system as a 
whole, and allow for partitioning of functionality. 

8 The methodology must provide a range of complementary viewpoints 
of the design (ie. for a RTS - Control, Process and Data). 

A study by the ISA Project and the Development Route team resulted in 
the choice of the Ward and Mellor methodology [Ward and Mellor 1985], 
using the design capture tool Excelerator RTS [Index Technology Exceler- 
ator Series 1989]. 
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The Ward and Mellor methodology is based on the SADT (Systems Analysis 
and Design Technique) developed and marketed by Ed Yourden [Yourden 
and Constantine 1979] and Tom de Marco [De Marco 1978]. The Ward and 
Mellor methodology extends the traditional Data Flow diagram with the 
introduction of Control Transformations and Control Flows. Control 
Transformations are an essential aspect of RTS analysis and design and 
allow for a state view of the system in the form of State Transition Diagrams. 
Control Flows allow for the signalling of events both within (temporal) or 
external to the System. 

Excelerator RTS is a RTS analysis and design support tool which incorpor¬ 
ates graphics facilities, a data dictionary, analysis reports and a documenta¬ 
tion production facility. It is particularly suited for use with the Ward and 
Mellor methodology and supports the full range of graphs required. 

This combination of Ward and Mellor/Excelerator fulfilled all the above 
objectives, as did several other possibilities. The combination also however 
offered certain advantages which are listed below. 

2.1.2 Advantages of the adoption of Ward and Mellor/Excelerator 

1 Excelerator RTS was the most widely used design capture tool, and the 
Ward and Mellor methodology had been adopted by many major in¬ 
dustries. 

2 As Excelerator ran on IBM PC compatibles, an ICL DRS M60/80 
network could be used. 

3 There were well established “User Group” and “Hot Line” facilities, 
together with a range of specialised training courses. 

4 The assessment of the design quality (at reviews and elsewhere) was 
greatly facilitated. This was as a direct result of applying the more formal 
criteria of: 

• Cohesion - How well the components fit together. 

• Coupling - Inter-module dependency & extent to which the effects of 
change need to be considered. 

• Information Hiding - The extent to which design decisions are con¬ 
cealed from “view”. 

These criteria can be divided further, as specified in [Page-Jones 1988]. 
Yourden has also attempted to assign weightings to the various sub-levels 
[Bergland and Gordon 1981] which is useful in that it highlights the more 
important aspects of the above criteria. 

2.2 Methodology introduction to project 

The emphasis was on the creation of an “Awareness of Design and the 
Design Process” rather than the teaching of specific design skills. 
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The limitations of our perceptions can be traced beyond the flow chart to 
the Von-Neuman architecture. This architecture, performing a sequence of 
operations, one at a time, on elemental data items “acted as a powerful 
symbol and conditioned our perceptions” [Page-Jones 1988]. People nur¬ 
tured in traditional DP environments tend to see a problem in terms of 
sequences and operations to be performed. An attempt was made in the 
project to break this “Von-Neuman mind-set” and to emphasise an “Outside 
In” rather than a “Top Down” design approach. 

The limitations of currently used methods (flow charts, text) were explained 
to the Project and the benefits of the new methodology were emphasised. It 
was shown that flow charts were incapable of capturing a RTS (eg. no way 
of representing concurrent processing or the responding to events). Examples 
demonstrating the sequential nature of flow charts were used to show that 
they could only be used in a restricted environment. Textual representation 
of design was shown to be unsuitable for many reasons (eg. ambiguity, 
difficulty of detecting omissions). A “textual design is largely dependant on 
the grammatical ability of the designer”. 

The quality measures of Cohesion and Coupling were used to highlight the 
additional clarity gained by using the Ward and Mellor methodology. This 
more than any other factor proved to be most influential in achieving a 
general staff acceptance of the new methods. 

Staff training consisted of the CTD2 (Core Technical Training) course, 
internal presentations and individual study of the methodology via applica¬ 
tion to ISA functionality. This required a substantial investment in time and 
energy and involved a large learning curve. 

3 Ward and Mellor usage 

ISA is a complex real time system. No information on the Ward and Mellor 
methodology (textbooks, worked examples, etc) could be found demonstrat¬ 
ing its use for the modelling of such a system. The use of this methodology 
in the design of ISA therefore broke new ground and involved innovative 
uses of the methodology features. 

3.1 ISA Analysis and Design History 

The analysis and design phases of ISA followed the Ward and Mellor model 
hierarchy. Note however that the terms Logical and Physical are taken from 
[McMenamin and Palmer 1984] whilst in [Ward and Mellor 1985] the terms 
Essential and Implementation are used. The terms Logical and Physical 
were adopted by the project as they emphasised the lifecycle stages of Logical 
Analysis and Physical Design. 

The modelling began with the construction of a High Level Logical (or 
Essential) Model. Although it was feasible to resist any work on the Physical 


ICL Technical Journal May 1991 


639 


Model until completion of the Logical Model, the approach chosen involved 
the production of a High Level Physical (Implementation) Model at an 
earlier stage and the iteration between these Logical and Physical Models 
was found most useful (as it was throughout the analysis and design phases). 
Though shown as a separate phase on the diagram below, the Low Level 
Logical Model was in fact produced as part of Low Level Physical Design 
and a full understanding of the Low Level Logical Analysis phase has only 
been gained in retrospect. The Low Level Physical Model from which the 
implementation of ISA took place therefore also contained the Low Level 
Logical Model. Details of the analysis and design phases associated with 
these models can be found in Sections 3.2.1 - 3.2.4. 

At specific stages in the analysis and design phases “Fagan” style reviews 
were held before proceeding to the next phase. 

Though at times iteration back to the Logical Model lagged behind develop¬ 
ments on the Physical Model this iteration was always carried out and the 
High Level Logical Model now represents a clear, implementation-free 
model of ISA. 


The ISA Analysis and Design History is summarised in Fig. 3.1. 


Constraints 
(eg OSA 
Structure) 



Fig. 3.1 ISA Analysis & Design History 

As shown on the diagram above, though Ward and Mellor practice was 
followed, outside constraints influenced the analysis and design at an earlier 
stage than might have been expected and changing and additional require¬ 
ments had to be accomodated throughout all the phases. 

One major constraint was the requirement that for reasons of time and cost, 
the basic structure of OSA was to be carried forward to ISA. 
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3.2 Features used 


Throughout the analysis and design phases the need to define and maintain 
separate, but complementary, Process, Control and Data views was kept in 
mind. The bulk of the design comprised Process decomposition with the 
Control aspects appearing only after some decomposition had taken place. 
Thus separate but interlinked Process and Control views were produced. A 
Data view was included in the High Level Logical Model but though in 
itself it was found useful it was not developed any further. 

The ISA design phases are considered in the subsections below and the 
Ward and Mellor features that were employed in each are described. Prob¬ 
lems encountered are also mentioned. A number of examples are included. 
These give a flavour of both how the features were used and of the complexity 
of ISA. 

3.2.1 High level logical analysis The logical model that was constructed 
was an Essential Model as defined in [Ward and Mellor 1985] and consisted 
of two parts: a description of the environment in which the system operates, 
the Environmental Model, and a description of the required behaviour of 
the system, the Behavioural Model. 

The Environmental Model comprised the Context Diagram, the top level 
Transformation Graph which showed the External Entities with which ISA 
communicates and the nature of these communications, together with the 
Event List. The ISA Context Diagram can be found in Fig. 3.2. An Event 
List is a list of all external events where an external event is defined, in 
[Ward and Mellor 1985], as “something arising in the System’s environment 
at a specific point in time which requires a preplanned response”. 

In the Behavioural Model the ISA Process was decomposed using a set of 
Transformation Graphs (TRGs). The Control View of ISA appeared in this 
decomposition as in addition to Data Processes, Control Transformations 
were introduced. These were described by State Transition Diagrams (TRDs) 
which modelled the ISA States and Process Modes. Further detail was 
provided where necessary by Matrix Graphs (MTRs). The use of TRDs to 
show the possible ISA States and the allowable State changes together with 
MTRs to specify the detail of these State changes proved to be a powerful 
and accurate method of modelling the complex control necessary for ISA. 

The Behavioural Model also contained the Information Model. This repres¬ 
ented the major Data to be handled by ISA and comprised a single Data 
Entity Relationship Diagram (ERA). 

3.2.2 High level physical design The High Level Physical Model was 
derived from the High Level Logical Model and in it the ISA functionality 
was incorporated into the basic structure derived from OSA and the compon¬ 
ent ISA Tasks were identified and defined. Note that where the term Task 
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Fig. 3.2 ISA Context Diagram 













































































is given a capital letter this refers to an ISA Task which should not be 
confused with the general use of the term in [Ward and Mellor 1985]. An 
ISA Task is defined as “a collection of related processes grouped together 
to form a convenient unit of implementation”. These processes are generally 
associated with a particular external entity (eg PCS - Power Control System). 

In phase one of High Level Physical Design the start point was the Context 
Diagram (TRG) and the ISA Process was then decomposed using a set of 
Transformation Graphs (TRGs) down to the level at which the component 
ISA Tasks were identified. As with the High Level Logical Model, Control 
Transformations which were introduced were described by State Transition 
Diagrams (TRDs) and further detail was provided where necessary by 
Matrix Graphs (MTRs). The Information Model from the Essential Model 
was not carried over and pursued. 

In phase two of High Level Physical Design the Tasks were decomposed 
using Transformation Graphs (TRGs) and State Transition Diagrams (TRDs) 
until they reached the “elementary process” stage ie became sufficiently 
concise and compact that they would not benefit from any further decom¬ 
position. Figure 3.3 shows the TRG 1.3.1 Reset Task. 

The need for a standard approach to modelling Task inputs and outputs 
became evident as the High Level Physical Design progressed and a standard 
“Task Model” was produced. The lack of such an approach until late in 
the day gave rise to some unnecessary design differences between Tasks in 
both the High Level and the Low Level Physical Models. 

The High Level Physical Model described above represents the final situ¬ 
ation. Initially it was thought that the “primitive process” stage had been 
reached with the definition of the ISA Tasks which were then further 
described using Structure Diagrams and Structure Charts in the subsequent 
analysis and design phases (see below). This approach was fairly successful 
but ISA Tasks contained complex functionality which was not visible in 
Structure Diagrams and Structure Charts. Some issues were therefore not 
properly considered and the current rigorous design was only achieved after 
the second phase of High Level Physical Design had been completed and 
the “missing” levels of TRGs and TRDs produced. 

In retrospect it is clear that the control side of ISA was allowed to become 
too complex, with an excess of states and substates. To an extent this was 
caused by confusion between process and state. At times it seemed that 
every process introduced had to have an associated state or substate! This 
uncomfortable situation was tackled in the final iteration back to the High 
Level Logical Model and a much simpler control view resulted. This is 
shown in Fig. 3.4, the TRD 0.1 Control ISA. 

3.2.3 Low level logical analysis Low Level Logical Analysis was in fact 
carried out as the first stage of Low Level Physical Design and the Low 
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Fig. 3.4 0.1 Control ISA 


Level Logical Model produced was therefore a component of the Low Level 
Physical Model! Structure Diagrams (STDs) were used to describe what the 
processes identified at the higher levels should do. An example STD, ILR 
01 Process in Line Recowry, can be found in Fig. 3.5. 

The use of STDs during Low Level Logical Analysis could be considered 
suspect as these diagrams are fundamentally procedural. There was therefore 
a risk that the model would describe how the process was to be implemented 
rather than what the process should do. Other methods (eg non-graphic, 
non-procedural specification using pre and post Conditions, decision trees) 
were considered but rejected as being unsuitable for the design of the 
complex low level ISA data processes. Another possibility here would be 
the use of State Transition Diagrams, and if a “State View” was considered 
beneficial these would be the ideal representation. 

Despite the above reservations the adoption of STDs proved successful with 
their pictorial nature being a very useful attribute for this stage in the 
lifecycle. Any future use of STDs for Low Level Logical Analysis should 
concentrate on their selection and repetition features. However, as stated in 
[McMenamin and Palmer 1985], “if there is an essential order among the 
actions that make up an essential activity, you’ve got to have some way of 
stating it”! 
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Fig. 3.5 ILR 01 Process In Line Recovery 


It would not be accurate to describe the Low Level Logical Analysis of ISA 
as a separate phase though with hindsight its value is now apparent and 
greater emphasis would be placed on it in any future application of the 
Ward and Mellor methodology. 

3.2.4 Low level physical design In the first phase of Low Level Physical 
Design the ISA Tasks were broken down into their component procedures 
and represented on Structure Charts (STCs). This phase used the (logical) 
process analysis described in the Structure Diagrams of the Low Level 
Logical Model to determine the physical procedure breakdown. Figure 3.6 
shows the STC ILR 01 Ur —start. 

The next phase, the procedural description phase, was the final design stage 
and represented the level immediately above the code. Structured English 
was used for this phase, this being a relaxed form of pseudo code with no 
precise syntax. Structured English was found to be formal and restricted 
enough to be unambiguous and its adoption involved only a very short 
learning curve. 
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The Control and Data Flow split which had been carefully introduced at 
the higher levels became somewhat merged in the Low Level Physical 
Design. This was largely due to the constraints placed on the design by the 
carrying forward of the basic OSA structure onto ISA. Whilst this made 
for a less clear design it did not however affect its rigour. 

3.3 Lessons learned and future considerations 

3.3.1 Data schema Throughout the analysis and design phases the em¬ 
phasis was placed on ISA being an ‘Active” or ‘‘Transformation Driven” 
system [Ward and Mellor 1985]. The High Level Logical and Physical 
Models are therefore almost entirely composed of Transformation Schema 
(TRGs and TRDs). Whilst the decision about the nature of ISA was correct, 
the fact that no attempt was then made to view ISA as a “Passive” or 
“Stored Data Driven” system meant that the Information Model was not 
pursued at all. Some development of Data Schema (ERA) would certainly 
have helped to increase the clarity of the data which ISA handled and would 
also have helped to improve its partitioning. 

3.3.2 Control view As mentioned in Section 3.2.2, there were problems 
with the ISA control view. Whilst the control view within the High Level 
Logical Model is now concise and encompasses the whole of ISA the same 
cannot be said for the other ISA Models. Iteration back through these 
would obviously improve things (and perhaps change the implementation!) 
but for the future the possibility of using State Charts [Harrel 1987] for the 
control view should be investigated. These introduce inter-level transitions 
and a broadcast mechanism for communication between concurrent com¬ 
ponents but are not however available on Excelerator. 

3.3.3 Data scope In the Structure Charts of the Low Level Physical 
Model it was difficult to represent the scope of data. As a complement to 
STC’s the use of Structure Graphs [Buhr 1984] could be beneficial here as 
these graphs would allow Data to be declared as local to a Task or as shared 
by several or all Tasks. The Structure Graph is not however supported by 
Excelerator. 

4 Conclusions 

A significant improvement in productivity was achieved in the production 
of ISA which was combined with a major improvement in delivered product 
quality. The potential now exists for the exploitation of the acquired staff 
skills and for the reuse of aspects of the design for future support processes. 

4.1 Improved product 

Major improvements were achieved in ISA as compared to its predecessor, 
OSA. There was increased focus on the analysis activities rather than a 
headlong rush to implement and the separation of Process from Control 
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greatly improved design clarity. The development of an ISA “house style” 
(applicable to any methodology) made design and code reviews highly 
effective and promoted early bug removal. There were difficulties in introdu¬ 
cing and evolving a new methodology at the same time as designing a 
complex system but these were successfully overcome. 

The bug density in the product delivered to pre-release Integration staff was 
down by a factor of 5 which offered major reductions in integration costs 
and timescales. Relevant ISA statistical information can be found in [Murray 
1990]. This shows that design faults had been largely eliminated from the 
coding and testing phases (only 3% of the bugs reported there were attribut¬ 
able to design errors as against 40% for OSA!) and that only 55 bugs 
remained in the product on delivery to Integration compared with 275 for 
OSA. 

4.2 Advantages 

There were many advantages in using the Ward and Mellor methodology 
and Excelerator. Staff were highly motivated by the opportunity to increase 
their skills and the product design was clear and unambiguous, so simplifying 
all subsequent development phases. As design documentation was generated 
by the design tool this greatly reduced the problems of document production 
and design maintenance. The application of professional methods to the 
design of ISA enabled it to be presented positively and went a long way to 
combat the poor Support Processor image mentioned in Section 1.2 (Back¬ 
ground). 

4.3 External documents 

The methodology was used throughout the ISA project and designs were 
expressed using its representational options but it was also necessary to 
communicate externally in an appropriate and acceptable manner. For many 
of the key external documents and interface definitions the only sensible 
option was to use standard English text. Ward and Mellor representation 
could have been employed but external staff and customers might then have 
been irritated by the use of an unfamiliar method of representation and by 
an insensitive approach which implied a requirement on them to understand 
it. 

4.4 Subsequent interest by others 

Having gained experience in the introduction and use of the methodology 
and supporting tools, the project has been able to offer advice and consult¬ 
ancy to other groups with similar problems. The view that has been offered 
is that the choice of methodology is the first step after which suitable tools 
can be selected but that the methodology must be tuned to the specific 
problem domain to be addressed. The selection of Ward and Mellor was in 
response to the real time nature of ISA. 
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4.5 Design reusability 


The methodology used has produced two complementary representations 
of the system (Essential and Implementation) both of which comprise separ¬ 
ate Process, Control and Data views. These representations have been 
produced in a range of levels of design detail. Design fragments are thus 
available for reuse from either representation and with different levels of 
detail. This does not pre-suppose that an Evolutionary Support Processor 
or Process is inevitable on any future mainframe but it envisages that design 
reuse may in many cases be more subtle and innovative. The System Design 
of any new mainframe is likely to take note of past solutions and constraints 
while allowing scope for novel and revolutionary options. 

With the future in mind work has already begun on the production of a 
range-independent model of the Support Process in the form of an NMU 
Essential Model (The NMU is the Node Management Unit, the logical unit 
responsible for management and support of the Node). 
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Alan Fuller undertook academic training as a research chemist gaining a 
Doctorate in High Temperature Gas Phase Kinetics or “explosions” to the 
layman. Much of the analysis of the research was done using computers, 
which led to a career into the computer industry. After working for Oxford 
University in their Computing Laboratory on communications software for 
front end processing systems, he joined ICL in 1977. 

He has held a number of positions in ICL always working in a networking 
and communications environment and is currently responsible for the stra¬ 
tegic marketing of products for Public Network Operators worldwide. 

Javier Larraz I ribas 

Javier Larraz Iribas graduated from Universidad Complutense, Madrid in 
Business Sciences 1989. 
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Joined ICL in September 1989 and completed the graduate induction pro¬ 
gramme in the UK, being assigned to the ISDN unit in Networks Industry 
and to the CARRIER 400 team in Message Handling Systems within 
Product Operations. 

Back to Spain in September 1990 as the Product Manager for VANS. 
Martin Jones 

Martin Jones was a College Lecturer in Mathematics prior to returning to 
Postgraduate study in 1986. He graduated from Manchester University in 
1987 with an MSc in Computer Science and joined ICL in the same year. 
The majority of his work there has been involved with the design and 
implementation of NSX (Node Support Computer for SX) Firmware and 
with the adoption of new methods. He is currently on secondment to the 
VME Software Factory where he is looking at the introduction of new 
methods and tools. 

Kevin Lewis 

Kevin Lewis joined STC Technology Ltd after graduating from Warwick 
University with a second class degree in Computer Systems Engineering. He 
works in the Knowledge Based Systems group at STL. He has been involved 
in a number of projects at STL, notably the Locator Tree Editor, a matrix 
analysis tool, and has participated in the ESPRIT project within which the 
knowledge based systems methodology, KADS, was developed. He is cur¬ 
rently working on an intelligent knowledge based help desk facility. His 
interests lie in the fields of qualitative modelling, neural networks and logic 
programming. 

Peter Mole 

Was born in London England in 1953. He received his B.A. and Ph.D. from 
Cambridge University, England in 1974 and 1978 respectively. 

From 1978 to 1988 he worked on the development of SOS technology and 
the development of device modelling at GEC’s Hirst Research Centre. 

Since 1988 he has been working at STC Technology where he is leading the 
process and device modelling group. The major interests of the group are 
the modelling of the process and operation of high performance polysilicon 
emitter bipolar devices. 

Don Murray 

Don Murray joined ICL in 1973 having graduated from Dundee University 
with an Honours Degree in Physics. His induction period was spent working 
on 2900 Series test software and test operating systems and since 1975 he 
has worked as a manager and designer on Support Systems for ICL Main¬ 
frame Computers. This has involved the SCP (System Control Processor 
for S-Series) from 1975 to 1981, the NSC (Node Support Computer for 
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L-Series) from 1981 to 1986 and from 1986 to 1990 the NSX (Node Support 
Computer for SX). He is currently manager of a team investigating design 
verification for future mainframes. 

M. Orange 

Marc Orange went to the University of Paris XI for a D.E.S.S. (Diplome 
d’Etudes Superieures Specialisees) in Electronics and Computing. 

Since the beginning of his professional life, he has focused on telecommuni¬ 
cation protocols and techniques. For 6 years he worked on several X25, 
X21 or ISDN projects for LANs and PCs. He joined Network Applications 
as a consultant to adapt the ICL ISDN product (DeskTop Conferencing) 
to French specifications. 

Martin Perrett 

Martin Perrett obtained a degree in Mathematics from Oxford University, 
New College in 1984. He has been involved in the computer industry since 
October 1985 when he joined ICL. After an initial 3 month period he joined 
Strategic Systems where he has worked on a number of applications and 
research projects. 

He currently works as a Senior Consultant for Strategic Systems (Asia) in 
the area of logistics and decision support using DECISIONPOWER. He 
was involved as the senior designer on the Hong Kong International Ter¬ 
minals project and is currently involved in a number of other AI projects 
within the region. 

George Rouse 

Served a mechanical engineering apprenticeship with Davey Paxman 
(Diesels) Colchester. Was conscripted for National Service in the RAF in 
1956, trained and served as a Ground Radar Fitter before being commis¬ 
sioned as an Air Electronics Officer. Having flown two tours each on 
Shackletons and Vulcan B2’s with around 2000 flying hours on each type, 
retired with the rank of Flight Lieutenant in 1970 and joined ICL in the 
Stevenage laboratories. He worked in development prior to moving to 
support roles in Computer House, Euston, and then for three years integrat¬ 
ing OEM systems, with the first delivered 2960, on the Opcon Pilot project 
at Northwood. On completion of the project took the role of Manager High 
Volume Products Support at Arlesey for GPCD, then back to Stevenage as 
Manager Small and Distributed Systems Support, progressively integrating 
units from Stevenage, Arlesey, Kidsgrove and Cockfosters into a unified 
Office and Retail systems support team. More recently, as Manager Office 
Systems Services Development for ICL(UK)CS, was also concerned with 
product life cycle management and performance risk analysis for major sales 
and services bids. Having retired from ICL in January 1991, he is currently 
managing the consultancy Talaris Ltd. 
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A. Spiracopoulos 

After graduating from University of Toronto in 1984 as Bachelor of Science 
(Computer Science), Andreas Spiracopoulos took a D.E.A. (Diplome 
d’Etudes Approfondies) in computing in Paris in 1989. 

He first worked for the Ontario Ministry of Housing developing a specific 
application for that Ministry before joining the Ontario Hydro Corporation 
in 1987 as a Systems Analyst. He joined ICL Network Applications (Paris) 
in 1989, where his role was to adapt the ICL/ISDN application to France 
Telecom specifications. 

C.B. Taylor 

Colin Taylor is Manager of Standards in ICL Systems Integration Division. 
He is a graduate of Manchester University, a Chartered Engineer, and a 
Fellow of the British Computer Society. He has held senior positions in the 
development of many of the major successful ICL product ranges from 1900 
onwards, in systems design, architecture and development management 
roles. He was one of the originators of the VME architecture and was 
chairman of the companywide group that laid down the supervisor interfaces 
and architecture definitions. His team created and developed the DME and 
CME systems, and he was Technology Centre manager responsible for the 
architecture of the ME29 range. Since 1982 he has been particularly con¬ 
cerned with Open Systems, the world UNIX scene and ICL’s UNIX tech¬ 
nical strategy. He is a founder of X/Open, an Alternate Director on the 
Board of the X/Open Company, and the ICL manager on the X/Open 
Technical Management Group. He has recently also become responsible for 
Standards Strategy for the Division. 

Roger Whetton 

Roger Whetton joined ICL in 1968 after gaining a BSc (Hons) in Chemical 
Engineering at University College London. He worked on 1900 and 2900 
Series test software until 1980 and since then he has been involved with 
Support Systems for ICL Mainframe Computers. In this capacity he has 
worked on the design and implementation of NSC (Node Support Computer 
for L-Series) Firmware and latterly he has been responsible for the design 
of NSX (Node Support Computer for SX) Firmware which has employed 
Structured Design Techniques. 

Kam-Fai Wong 

Kam-Fai Wong received his B.Sc. and Ph.D. from the Department of 
Electrical Engineering of Edinburgh University in 1983 and 1987, respect¬ 
ively. For his Ph.D. thesis, he designed and developed a hardware garbage 
collector system for real-time AI applications. He joined the Computer 
Science Department of Heriot-Watt University in 1986 and worked as a 
research associate on the Prolog Database Machine Project. In 1988, he 
joined the System Software Engineering Department at Unisys, Livingston, 
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Scotland. There he worked briefly for a year as a software engineer designing 
a real-time kernel. Since the end of 1989, he has been working for the 
European Computer-Industry Research Centre (ECRC) at Munich. He is a 
researcher in the Computer Architecture group at ECRC and is currently 
leading a small team investigating performance issues of parallel database 
systems. 
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Guidance for Authors 


1. CONTENT 

The ICL Technical Journal has a large international circulation. It publishes papers of high standard having 
some relevance to ICL’s business, aimed at the general technical community and in particular at ICL’s users 
and customers. It is intended for readers who have an interest in the information technology field in general 
but who may not be informed on the aspect covered by a particular paper. To be acceptable, papers on 
more specialised aspects of design or applications must include some suitable introductory material or 
reference. 

The Journal will usually not reprint papers already published, but this does not necessarily exclude papers 
presented at conferences. It is not necessary for the material to be entirely new or original. Papers will not 
reveal matter relating to unannounced products of any of the STC Group companies. 

Letters to the Editor and reviews may also be published. 

2. AUTHORS 

Within the framework defined by §I the Editor will be happy to consider a paper by any author or group 
of authors, whether or not an employee of a company in the STC Group. All papers are judged on their 
merit, irrespective of origin. 

3. LENGTH 

There is no fixed upper or lower limit, but a useful working range is 4000-6000 words; it may be difficult 
to accommodate a long paper in a particular issue. Authors should always keep brevity in mind but should 
not sacrifice necessary fullness of explanation to this 

4. ABSTRACTS 

All papers should have an Abstract of not more than 200 words, suitable for the various abstracting journals 
to use without alteration. The Editor will arrange for each Abstract to be translated into French and German, 
for publication together with the English original. 

5. PRESENTATION 

5.1 Printed (typed) copy 

Two copies of the manuscript, typed l|/2 spaced on one side only of A4 paper, with right and left margins 
of at least 2.5 cms, and the pages numbered in sequence, should be sent to the Editor. Particular care should 
be taken to ensure that mathematical symbols and expressions, and any special characters such as Greek 
letters, are clear. Any detailed mathematical treatment should be put in an Appendix so that only essential 
results need be referred to in the text. 

5.2 Diagrams 

Line diagrams will if necessary be redrawn and professionally lettered for publication, so it is essential that 
they are clear. Axes of graphs should be labelled with the relevant variables and, where this is desirable, 
marked off with their values. All diagrams should have a caption and be numbered for reference in the text, 
and the text marked to show where each should be placed - e.g. “Figure 5 here”. Authors should check that 
all diagrams are actually referred to in the text and that all diagrams referred to are supplied. Since diagrams 
are always separated from their text in the production process these should be presented each on a separate 
sheet and, most important, each sheet must carry the author’s name and the title of the paper. The diagram 
captions and numbers should be listed on a separate sheet which also should give the author’s name and 
the title of the paper. 

5.3 Tables 

As with diagrams, these should all be given captions and reference numbers; adequate row and column 
headings should be given, also the relevant units for all the quantities tabulated. Short tables can be given 
in the text but long tables are better submitted on separate sheets and these, as for diagrams, must carry the 
author’s name and the title of the paper. 

5.4 Photographs 

Black-and-white photographs can be reproduced provided they are of good enough quality, they should be 
included only very sparingly. Colour reproduction involves an extra and expensive process and will be agreed 
to only exceptionally. 
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5.5 References 

Authors are asked to use the Author/Date system, in which the author(s) and the date of the publication are 
given in the text, and all the references are listed in alphabetical order of author at the end. 
e.g. in the text: further details are given in [Henderson 1986]” 

with the corresponding entry in the reference list: 

HENDERSON, P. Functional Programming, Formal Specification and Rapid Prototyping. IEEE Trans, 
on Software Engineering 1986, SE-12, 2, 241-250. 

Where there are more than two authors it is usual to give the text reference as “[X et al ...]”. 

Authors should check that all text references are listed, and only text references; references to works not 
quoted in the text should be listed under a heading such as “Bibliography” or “Further reading”. 

5.6 Style 

A note is available from the Editor summarising the main points of style - punctuation, spelling, use of 
initials and acronyms etc. - preferred for Journal papers. 

6. REFEREES 

The Editor may refer papers to independent referees for comment. If the referee recommends revisions to 
the draft the author will be asked to make those revisions. Referees are anonymous. Minor editorial 
corrections, as for example to conform to the Journal’s general style for spelling or notation, will be made 
by the Editor. 

7. PROOFS, OFFPRINTS 

Printed proofs are sent to authors for correction before publication. Authors receive 25 offprints of their 
papers, free of charge, and further copies can be purchased; an order form for copies is sent with the proofs. 

8. COPYRIGHT 

Copyright in papers published in the ICL Technical Journal rests with ICL unless specifically agreed otherwise 
before publication. Publications may be reproduced with the Editor’s permission, which will normally be 
granted, and with due acknowledgement. 
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